Choose a format
Existing V1 feeds continue to work without changes. An unversioned{"data": [...]} document, or one declaring "schema_version": "1.0", uses the existing standard-tier format.
V1.1 declares "schema_version": "1.1" and publishes service_tiers inside each model. The importer selects the format from the document. URL query parameters such as ?format=phaseo-v1.1 are optional conventions for your endpoint; Phaseo does not infer a version from the URL.
Download the V1 schema, V1.1 schema or V1.2 schema. Unsupported versions are rejected explicitly.
V1.2 data policies
V1.2 adds capability-specific training and retention declarations to each service tier. You can publish V1.2 at any time. Phaseo validates declarations on import, but they grant no guarantee until Phaseo approves your policy source. V1 and V1.1 feeds remain supported. V1.2 also accepts optional model-level or tier-leveldeclarations for model identity, typed input/output limits, parameter descriptions, scoped pricing and capacity, discounts, and deployment details. These are validated and retained for review. They do not automatically enable parameters or change billable prices, capacity enforcement or residency guarantees. Validation feedback identifies stored declarations; continue publishing effective prices and capabilities through their existing fields.
Set schema_version to "1.2" and add a data_policy object to each applicable tier:
data_policy value, not a complete feed. Capability IDs are canonical: use text.generate even when the model declares responses or chat.completions.
The declaration covers both prompts and outputs across the upstream processing chain. It does not describe billing metadata. Training values are unknown, may_train, no_train, opt_out_available, and enterprise_no_train. Retention modes are unknown, none, transient, fixed, and until_deleted. Use zero days for none, a positive maximum duration for transient/fixed, and null for unknown/until-deleted.
Declare required agreements with contract_mode: none, customer_agreement, or enterprise_agreement. Required account settings are objects with id, description, and HTTPS documentation_url in the account_settings array. Conditional programmes use zdr_eligibility: "conditional" and cannot declare an active true guarantee. They remain informational until Phaseo can verify fulfilment.
Phaseo approves the policy source independently. The feed cannot mark a declaration verified. This release grants active ZDR only for unconditional text generation on non-batch offers, with no training and no content retention. Hosting a model yourself does not by itself declare ZDR.
After an offer adopts feed-managed policy, setting false, sending null, omitting its declaration, or downgrading the feed version withdraws that guarantee. Manual Phaseo overrides are maintained separately. Positive declarations expire after 24 hours without successful catalog validation; approval revocation does not require a new provider fetch.
Publish normalized tiers
Do not use provider-specific tier names as normalized IDs.
priority remains a supported caller alias for Fast; catalogs publish fast.
Fast, Ultrafast and Flex selection is supported on text generation requests. Batch runs through the separate Batch API and still requires an installed provider Batch integration; publishing a tier does not install that integration. For uploaded provider-native files, use the declared Batch model ID or submit requests inline so Phaseo can translate it.
Use the same canonical model ID for its service tiers. Different models need separate canonical identities. Tiers inherit the model’s capabilities, limits and release schedule. Each tier declares its own upstream model ID, availability and effective pricing.
"service_tier": "fast", its effective prices, and a distinct upstream model ID for that offer. If the provider selects its lane using a native parameter instead, use the same upstream model ID and declare "upstream_service_tier": "priority" or "fast". Omit that field when the model ID selects the lane. Standard accepts default or standard; Flex and Ultrafast accept their corresponding values. Phaseo rejects nonstandard synchronous tiers that have no distinct model ID or native selector.
Every tier needs explicit pricing, including output and any cache/media meters you bill. Zero prices are valid; negative prices, unknown meters, duplicate tiers and conditional rates are rejected. price_nanos remains the effective price after promotions. Publish a new snapshot when rates change; Phaseo keeps previous effective prices.
Declare rate limits
Declare the request and token limits your platform applies to Phaseo’s account in an optional top-levelrate_limits array. It works the same way in V1 and V1.1 documents. Leave out model for a limit across all of your models, or set it to the upstream provider_model_slug of any model or tier in the same document.
requests_per_minute, requests_per_day, tokens_per_minute and tokens_per_day. Each value is a positive integer or null, and each entry needs at least one value. Phaseo counts each limit globally across all of its traffic to you. A model limit applies in addition to the limit across all models.
Limits never block requests. As an offer’s traffic approaches a limit, Phaseo sends it a gradually smaller share. Once the limit is reached, Phaseo ranks the offer below other providers until the limit resets. A value that is too low only reduces your own share of traffic. For that reason, limits apply without review once your provider application is approved, usually within a minute.
When the array is present, it replaces your declared limits each time a changed feed imports successfully. An empty array removes them. Omit rate_limits to keep the limits you manage in provider settings. Phaseo rejects the whole snapshot, and keeps your current catalog and limits, if an entry names a model that is not in the document, repeats a scope, or uses a value that is not a positive integer. The rejection appears as Changes requested.
You can also edit limits in Provider settings → Your models → Rate limits. Those edits save separately from catalog changes. The catalog editor does not accept rate_limits.