> ## 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. # Apply to serve models on Millwork > Prepare your Provider application, prove control of your API domain, and follow the review path from your model API to a customer route. Apply to offer your existing model API through Millwork. You keep hosting it. Once a route is approved and enabled, customers with access can choose it for tasks with spending limits and output checks, then read the result and receipt. **Goal:** Submit your organization's Provider application and prove control of its API domain. **You are done when:** the application is recorded, the domain shows **proven**, and Provider workspace names the next review step. Organization approval and model-route approval are separate decisions. > **[Which service type should I choose?](https://docs.getmillwork.dev/concepts/provider-types.md)** > > Compare your own model API, a gateway, a cloud host, and publishing model files only. ## Who should apply Apply if your organization operates the API that serves model requests. An **organization owner or admin** must submit the application and have authority to accept the Provider Agreement for that organization. Use your existing Millwork organization and sign-in. During private testing, your organization also needs approved Millwork access. If **Settings > Provider** is unavailable, [contact support](https://docs.getmillwork.dev/help/contact.md) about access. If your organization does not have Millwork access, [contact Millwork to apply for the preview](https://www.getmillwork.dev/contact/). If you only publish model files, ask the organization running the inference API to apply. [Model files and hosted inference](https://docs.getmillwork.dev/concepts/provider-types.md#publishing-model-files) explains what your published release contributes. ## From your API to a customer's task A **model route** describes an exact model release at a provider endpoint. Your service keeps running on your infrastructure. This application does not upload a model or move its runtime onto Millwork compute. This diagram shows who acts from application through customer use; each review must finish before the dependent step can proceed. ```mermaid theme={null} --- config: flowchart: nodeSpacing: 16 rankSpacing: 22 padding: 10 diagramPadding: 8 themeVariables: fontSize: "16px" textColor: "#211F1B" --- flowchart TD A["You · Settings
Review and submit the application"] B["You · Provider workspace
Prove API-domain control"] C["Millwork
Review your organization"] D["You · Provider workspace
Submit exact model routes"] E["Millwork
Test and approve each route
Prepare it and enable customer access"] F["Customer dashboard
Choose, save and run a model
Read the result and receipt"] A --> B --> C --> D --> E --> F classDef customer fill:#EEF4F6,stroke:#7895A0,color:#211F1B,stroke-width:1px classDef decision fill:#F8F6F3,stroke:#B92B2B,color:#211F1B,stroke-width:1px class A,B,D,F customer class C,E decision linkStyle default stroke:#4B5563,stroke-width:1px ``` **Submitting an application does not approve a model or route, publish a model, start traffic, or authorize spending.** A route can be approved without being available to a particular customer. The [customer-use handoff](https://docs.getmillwork.dev/concepts/models-and-sources.md#from-provider-route-to-customer-use) explains those later checks. ## Prepare your application Have these details ready before opening the form. | Detail | What to prepare | | - | - | | Registered organization name | The legal entity accepting the Provider Agreement. | | Provider display name | The name customers may see for your service. | | API domain | The hostname serving your API, such as `api.example.com`. You need access to its DNS and HTTPS hosting for domain proof. | | Provider source ID | A stable identifier for your service in routes and feeds, such as `example-ai`. | | Service type | The role of this API: [direct provider, gateway, or cloud host](https://docs.getmillwork.dev/concepts/provider-types.md). | | Support page and privacy policy | Full HTTPS links to the pages for this service. | | Agreement authority | An owner or admin authorized to accept terms for the registered organization. | Keep provider credentials out of these fields. Domain proof and route metadata do not require putting an API key in your application. ## Submit and prove your domain **1. Start the application in Settings** Open [Settings](https://app.getmillwork.dev/settings), select **Provider**, and choose **Start application**. Confirm the signed-in organization, then enter the details above. Choose the [service type](https://docs.getmillwork.dev/concepts/provider-types.md) for the API you are supplying, even if your organization has other roles. **2. Review the current Provider Agreement** Open **Review agreement** and read the exact version offered. The [published Provider Agreement](https://getmillwork.dev/millwork/legal/provider-agreement) is available as a full-page reference. Select **I have reviewed** to return to the form. This records your review in the form; it does not submit the application or accept the agreement yet. Changing the registered organization or receiving a newer agreement requires review again. **3. Submit the application** Review the authority statement beside **Submit application**, then submit. This action records the application and agreement acceptance together. Continue after **Application submitted** and **In review** are confirmed. Use **Manage in Provider workspace** to continue. A **Provider workspace** is your organization's area for domain proof, profile changes, review status, model routes, and feeds. It remains the place to manage the application after submission. **4. Prove control of the API domain** In [Provider workspace](https://app.getmillwork.dev/provider), open **Domain control** and choose **Start domain proof**. Give the displayed values to the person who manages your domain. They must publish both: * the DNS TXT record with the exact displayed name and value; and * the HTTPS file at the displayed path with the exact displayed content. Choose **Verify proof** before the challenge expires. Continue when the domain shows **proven**. If the challenge expired or the domain changed, choose **Start a new proof** and publish the new values. **5. Follow the organization review** Read the status and next action in Provider workspace. Millwork reviews the organization after the agreement and domain requirements are met. | Status | What happens next | | - | - | | In review | Millwork reviews the organization. Keep the domain proof current. | | Changes requested | Read the reason, correct the profile, and resubmit it from Provider workspace. | | Approved | Prepare exact model routes for their own testing and review. | ## After organization approval In Provider workspace, choose **Submit model routes**. Each route needs an exact model identity, endpoint, region, data rules, price, and expiry. A **feed** is the set of route details you submit or update together. 1. Select a model identity offered by the workspace. If the required release is missing, ask support about that identity before substituting another. 2. Enter the route details and the [evidence required for your service type](https://docs.getmillwork.dev/concepts/provider-types.md#what-each-type-must-identify). 3. Choose **Check routes** and correct every finding. 4. Choose **Submit model routes**, then follow each route's status and next actor under **Routes**. **Check routes** checks your details; it does not submit them. After you submit, Millwork handles testing and approval, prepares approved routes to serve requests, and enables customer access. Under **Routes**, follow the current status and who needs to act next. When the route is available to an eligible customer, continue with [From provider route to customer use](https://docs.getmillwork.dev/concepts/models-and-sources.md#from-provider-route-to-customer-use). ## Correct a choice or recover a stopped step | What you see | Next action | | - | - | | You selected the wrong service type before submitting | Change it in the form, then review the completed application. | | You need to change the submitted service type or profile | In Provider workspace, open **Organization > Edit profile**. Saving restarts organization review and domain proof and withdraws the existing routes' approval. Arrange the change before saving an active service. | | A field is rejected | Correct the message beside that field. Keep the populated application. | | The agreement was updated while the form was open | Review the latest offer, then submit again. The application details remain in the form. | | Submission could not be confirmed | Keep the current form or application context. Check Provider workspace before starting a second application. | | A route is held, suspended, or unavailable to customers | Read its reason and next actor. A new feed alone does not lift a Millwork suspension. | > **Provider source ID and link validation** > > The Provider source ID identifies your service in route and feed records. > Start with a letter or number. Use up to 128 characters: letters, numbers, > dots, underscores, colons, slashes, or hyphens. Uppercase letters are allowed. > > For API domain, enter the hostname without `https://` or a path. Support and > privacy links need `https://` and must not include extra parameters after `?` > or a section after `#`. ## Get help preparing [Contact support](https://docs.getmillwork.dev/help/contact.md) with your organization, the service you operate, and the step where you need help. Include the application or route ID when one exists. Keep credentials and customer data out of the message. A request for help is separate from submitting the application or accepting its agreement. ## Give the preparation to your coding agent Use this brief to prepare the facts and domain work. An organization owner or admin still reviews and submits the application. ```text theme={null} Help prepare our Millwork Provider application. Read the current pages first: https://docs.getmillwork.dev/get-started/provider-onboarding.md https://docs.getmillwork.dev/concepts/provider-types.md Use https://docs.getmillwork.dev/llms.txt to discover related docs. If the Millwork documentation MCP is connected, use its read-only search and page tools; setup is at https://docs.getmillwork.dev/mcp/documentation. Identify the exact API we operate, who publishes its model, and whether we serve it ourselves, route to upstream APIs, or host another publisher's model. Explain the service-type choice. Do not infer it from our cloud vendor alone. List the application facts we have, missing facts, and who controls API-domain DNS and HTTPS hosting. If we only publish model files, explain the host handoff. Prepare a checklist for an organization owner or admin. Do not submit an application, accept legal terms, change DNS, enter credentials, start model calls, or claim a route is available without the required human approval and current product evidence. Keep secrets and customer data out of the checklist. ``` This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.