Provider Integration

Use Provider Integration when you want to list your own model supply on OpenModels. The flow follows the same public contract pattern as OpenRouter-style provider onboarding: apply, expose a standard models feed, submit snapshots from the management page, and let OpenModels validate and route eligible supply.

Integration flow

1. Apply as a Community or Verified provider from the OpenModels provider application page.
2. OpenModels stores your upstream API key securely and validates your submitted /models feed.
3. Implement a models endpoint that returns the standard { "data": [...] } response shape.
4. Manage model and pricing updates from the provider management page with email verification.
5. OpenModels validates each snapshot and updates model prices, supply labels, and default routes.

Community supply is built for fast listing after automated validation. Verified supply requires manual OpenModels review before it can be listed as Verified.

Community vs Verified

For Verified applications, OpenModels applies the latest valid saved snapshot when the application is approved. If no valid snapshot exists yet, the provider remains approved and the next valid snapshot can be applied.

Apply

Submit the provider application from:

https://openmodels.market/providers/apply

The form collects provider identity, contact details, gateway URLs, authentication type, upstream API key, data-policy details, and optional provider icon URL.

The upstream API key is encrypted at rest. OpenModels does not include the plaintext key in notification email. The success page shows submission status only; use the provider management page for later model and pricing updates.

Manage model updates

Open the provider management page:

https://openmodels.market/providers/manage

Sign in with the contact email used on the provider application. OpenModels sends a verification code to that email. After verification, the page shows every provider application whose contact_email matches the verified email.

From the management page you can:

• choose a provider application when the email owns more than one application,
• view the latest submitted and applied snapshots,
• edit models in the UI editor,
• paste or edit the strict JSON snapshot in the JSON editor,
• submit a new snapshot for validation and automatic apply.

The browser stores the management session in sessionStorage, so refreshing the page keeps the session until it expires. Signing out clears the local session.

Models endpoint

Your modelsUrl must return the OpenModels standard envelope:

{
  "data": [
    {
      "id": "example-org/example-model",
      "name": "Example Model",
      "created": 1781575605,
      "input_modalities": ["text"],
      "output_modalities": ["text"],
      "context_length": 1000000,
      "max_output_length": 64000,
      "provider_logo_url": "https://cdn.example.com/provider.svg",
      "pricing": {
        "prompt": "0.000000029",
        "completion": "0.000000294",
        "input_cache_read": "0.000000003",
        "image": "0",
        "request": "0",
        "duration": "0"
      },
      "supported_features": ["tool_calling", "reasoning"],
      "is_ready": true,
      "is_free": false,
      "discount_to_user": 0
    }
  ]
}

Rules:

• The top level must be { "data": [...] }.
• id is the public model ID OpenModels will route to your gateway.
• is_ready: false keeps the model in the saved snapshot but prevents active price or route listing.
• provider_logo_url is optional. If omitted, OpenModels can use the icon URL from your application, then fall back to the provider website favicon.
• pricing values must be decimal strings in USD per base unit. Use strings to avoid floating point precision drift.

Do not send an OpenAI-style /models response or a provider-specific custom shape.

Pricing

pricing can be an object or an array.

Object pricing creates one price group:

{
  "pricing": {
    "prompt": "0.000000029",
    "completion": "0.000000294",
    "input_cache_read": "0.000000003"
  }
}

Array pricing supports tiered or mixed-unit pricing:

{
  "pricing": [
    {
      "prompt": "0.000000029",
      "completion": "0.000000294",
      "range_start": 0,
      "range_end": 200000
    },
    {
      "prompt": "0.000000058",
      "completion": "0.000000588",
      "range_start": 200000
    },
    {
      "image": "0.02"
    }
  ]
}

Pricing units are always the smallest billable unit in the JSON payload. The Models table may display token prices as /1M for readability, but provider snapshots should still send per-token values.

OpenModels maps pricing fields by unit:

For tiered token pricing, range_start and range_end are input-token thresholds. Omit range_end for the final open-ended tier.

When a model has both token and non-token prices, OpenModels stores separate price rows by billing unit. The default route is created once per model and binds to the main price in this order:

1. Tiered token price
2. Flat token price
3. First valid non-token price

Invalid decimal strings, overlapping tiers, or malformed pricing fail the whole snapshot instead of partially listing the provider.

Submit snapshots

For most providers, use the UI or JSON editor at:

https://openmodels.market/providers/manage

The management page submits the snapshot with the email-verified management session.

For automation or existing integrations, OpenModels also supports the snapshot API:

POST /api/v1/providers/applications/{applicationId}/model-snapshots

Authenticate with a provider update token when OpenModels operations has issued or regenerated one:

Authorization: Bearer <providerUpdateToken>

The legacy update-token header is accepted for existing integrations:

X-Provider-Update-Token: <providerUpdateToken>

Example:

curl https://api.getopenmodels.com/api/v1/providers/applications/$APPLICATION_ID/model-snapshots \
  -H "Authorization: Bearer $PROVIDER_UPDATE_TOKEN" \
  -H "Content-Type: application/json" \
  -d @models.json

If the provider is disabled or rejected, OpenModels can still record the snapshot for audit, but it will not reactivate supply or write active routes.

Valid snapshots update the provider’s model and pricing configuration automatically. Community supply can apply after automated validation. Verified applications can save snapshots before approval; after approval, OpenModels applies the latest valid saved snapshot immediately, and later valid snapshots continue to update the same Verified supply. Malformed models or pricing reject the snapshot instead of partially updating routes.

Reliability expectations

OpenModels may test submitted gateway access and model availability before listing supply. Keep these behaviors consistent:

• Return early 429 responses when overloaded instead of queueing long-running work.
• Keep upstream authentication valid.
• Stream tokens as soon as they are available for streaming models.
• Use is_ready: false before announcements, maintenance windows, or temporary model removal.
• Keep pricing, context limits, modalities, and supported features current in each snapshot.

Use Model Routes for application-level route groups, and Chat Completions for request-time route.provider overrides.