Skip to main content
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?

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 about access. If your organization does not have Millwork access, contact Millwork to apply for the preview. If you only publish model files, ask the organization running the inference API to apply. Model files and hosted inference 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. 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 explains those later checks.

​
Prepare your application

Have these details ready before opening the form.
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, select Provider, and choose Start application. Confirm the signed-in organization, then enter the details above. Choose the service type 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 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, 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.

​
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.
  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.

​
Correct a choice or recover a stopped step

​
Get help preparing

Contact support 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.