> ## Documentation Index
> Fetch the complete documentation index at: https://docs.getmillwork.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Choose your provider service type

> Choose the role of the model API you operate, understand the evidence it needs, and distinguish hosted inference from model files.

Choose the type of **service you are supplying**, rather than a label for your
whole company. A model publisher releases a model. An API provider runs the
service that answers requests. They can be the same organization or different
organizations.

If you developed a model and serve it on rented cloud machines, you still
supply your own model API. Renting infrastructure alone does not make your
service a cloud-host type.

## Which type should I choose?

Follow the arrows for one service until your answer names a service type or
directs you to the organization running the API.

```mermaid theme={null}
---
config:
  flowchart:
    nodeSpacing: 16
    rankSpacing: 22
    padding: 10
    diagramPadding: 8
  themeVariables:
    fontSize: "16px"
    textColor: "#211F1B"
---
flowchart TD
  A["<b>Do you run the model API?</b><br/>No: ask its provider to apply."]
  A -->|Yes| B["<b>Do you serve your own model?</b><br/>Yes: direct provider."]
  B -->|No| C["<b>Do you forward to other APIs?</b><br/>Yes: gateway."]
  C -->|No| D["<b>Do you host another<br/>publisher's model?</b><br/>Yes: cloud host.<br/>Unsure: ask support."]
  classDef decision fill:#F8F6F3,stroke:#B92B2B,color:#211F1B,stroke-width:1px
  class A,B,C,D decision
  linkStyle default stroke:#4B5563,stroke-width:1px
```

If several roles fit, classify the particular endpoint you are applying to
provide. Ask [support](https://docs.getmillwork.dev/help/contact.md) before combining services with different
upstream or hosting responsibilities in one application.

| Service type in the form | Who runs the API and publishes the model? | Next step |
| - | - | - |
| **We serve our own models** | Your organization publishes the model and operates its API. | Apply as a direct provider for exact model releases. |
| **We route requests to other model providers** | Your gateway receives requests and forwards them to other providers' APIs. The original publisher remains distinct. | Apply as a gateway with a pinned upstream for each route. |
| **We host models in a cloud region** | Your service hosts a model published by another organization and operates the inference API. | Apply as a cloud host with the serving region and access requirements. |
| **We publish model files but do not run an API** | You publish release material; another organization must operate an inference API. | Ask that API provider to apply. This selection does not submit a serving-provider application. |

## What each type must identify

The type changes the evidence for an exact **model route**: one model release
served at an endpoint. All serving types need organization and domain review,
route testing, and separate approval before customer access.

**Direct provider**

**Example:** Your team develops a text model and serves its release through
your API, including when the machines are rented from a cloud company.

* Name the exact release served by the endpoint. A moving alias such as
  `latest` or `current` is not an exact release.
* Identify your API endpoint, region, allowed data, price, and route expiry.
* [Apply for the organization](https://docs.getmillwork.dev/get-started/provider-onboarding.md), then submit
  the exact release for route testing and review.

The provider and publisher are your organization; the infrastructure company
does not become the applicant merely by renting you machines.

**Gateway**

**Example:** A service receives one API request and forwards it to a model API
operated by another provider. OpenRouter illustrates this role.

* Name the exact model and upstream provider for each route.
* Pin that upstream and disable the gateway's own fallback for the route.
* Declare the data boundary and price for that exact pair.
* [Apply as the gateway provider](https://docs.getmillwork.dev/get-started/provider-onboarding.md). A different
  upstream or changed fallback setting needs a new route review.

The upstream provider's availability or review does not approve every route
through your gateway.

**Cloud host**

**Example:** You operate a hosted inference service for another publisher's
model. A region- and account-scoped cloud model service illustrates this role.

* Identify the exact model or profile and named serving region.
* Make account, entitlement, and applicable model-license requirements clear.
* Describe which endpoint serves the model, along with its price and data rules.
* [Apply as the API provider](https://docs.getmillwork.dev/get-started/provider-onboarding.md), rather than
  as the company that only supplies raw machines.

A raw GPU rental is not yet a model API. It needs a model runtime and a
supported inference interface before this serving-provider path fits.

## Publishing model files

Model-release material can include weights, configuration and tokenizer files,
a model card, license metadata, and immutable release references or checksums.
Serving engineers use that material to deploy a model. A customer can then
benefit through an eligible API route serving it.

The distinction is visible in [Hugging Face model repositories](https://huggingface.co/docs/hub/models)
and its separate [inference task APIs](https://huggingface.co/docs/inference-providers/tasks/index):
a repository contains model material; an inference service answers requests.
If one organization offers both, classify its inference service separately.

Published artifact evidence can help identify the model claimed by a route.
It does not prove what an endpoint actually serves. Selecting the files-only
option creates no inference endpoint, saved model, or run. This application
does not provide a separate publisher distribution, hosting, or payment path.
It also does not enroll raw compute or Millwork skill artifacts.

## Which capabilities fit this application?

**Provider role** describes who runs the service. **Capability** describes
what the endpoint does. Neither is the organization's review status, the
route's state, or the customer's billing arrangement.

This application accepts APIs that take text-chat requests and return one
complete text response. The route values are `openai_chat` and
`text_nonstream`. Other endpoint types need a separate integration; HTTPS
access alone is not enough.

| Capability and possible use | Does it fit this application? |
| - | - |
| Text generation: a support answer or research summary | Yes, for text-chat requests that return one complete text response. Submit exact routes for testing and review. |
| Embeddings: vectors for semantic search | Needs a separate integration defining vector inputs, outputs, limits, and validation. |
| Typed decisions or classification: route an item to a category | Needs a separate integration for the decision schema, probabilities or scores, and validation. Text containing a category is not a guaranteed typed value. |
| Ranking: order a candidate set | Needs a separate integration for candidate items, scores, and ranking validation. |
| Memory: retain and retrieve state across tasks | Needs a separate integration defining state ownership, organization isolation, retention, deletion, and retrieval. |
| Model files: a release a host can deploy | The API provider applies. Files can identify a release; they are not a callable model route. |

The uses above explain where a service could fit; the rows requiring another
integration are not runnable recipes. A separately registered
[agent endpoint](https://docs.getmillwork.dev/overview/arms.md) can have its own integration contract, but it
does not automatically admit an underlying service into the model catalog.

## How the customer gets access

A customer's **provider account** is the account used to access and pay for
model usage. It is separate from your Provider application.

* With the customer's own provider account, the customer establishes access
  and the provider bills that account.
* When Millwork provides eligible model access, its commercial and capacity
  requirements must also be met. Provider approval does not make that access
  available to every organization.

After route approval, activation and customer eligibility still determine
availability. Follow [From provider route to customer use](https://docs.getmillwork.dev/concepts/models-and-sources.md#from-provider-route-to-customer-use)
for the catalog, saved model, run, result, and receipt handoff.

## If you chose the wrong type

Before submission, change **Service type** in the application. After submission,
use **Provider workspace > Organization > Edit profile**. Saving a profile
change restarts organization review and domain proof and withdraws existing
route approval. The workspace explains the next action; arrange the change
before saving a service that already has active routes.

If the corrected choice is files-only, [contact support](https://docs.getmillwork.dev/help/contact.md) rather
than forcing the organization into another serving type. There is no
files-only conversion action in the current Provider workspace.

Once the type fits your service, [prepare your Provider application](https://docs.getmillwork.dev/get-started/provider-onboarding.md#prepare-your-application).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.