Skip to main content
Audience: Developers and customers using our multi-vendor model inference/API routing.

​
1) Key Terms

Vendor: The original provider that actually runs the model inference. Authorized Vendors: Vendors that we have integrated and vetted and to which we may route traffic. Model: A concrete, callable model instance (e.g., Model X vY). Request: A single inference/API call. Vendor Status: A vendor’s operational state (e.g., healthy / degraded / unavailable).

​
2) Modes & Availability Boundaries

​
Pinned Vendor Mode (you explicitly set vendor)

If the specified vendor is unavailable (“down”), we are not responsible for unavailability or failures on that request.

​
Auto Mode (vendor=auto, we route among Authorized Vendors)

If all Authorized Vendors for that model are unavailable (“down”), we are not responsible for the resulting unavailability or failures. Status Determination: Based on vendor status pages or announcements combined with our monitoring (e.g., error/timeout rates). Cross‑verification with both sides’ logs may be used.

​
3) Response-Header Verification (applies only when stream:false)

When a request uses non-streaming responses (stream:false), we attach verification headers to help confirm the actual vendor and account used to serve the request:
  • X-Vendor-Messages-Id — not masked; identical to the vendor’s messages_id for precise reconciliation and traceability. This value is not a credential and cannot be used to authenticate or invoke calls.
  • X-Vendor-Api-Key — masked/irreversibly derived from the vendor api_key used for the request. For verification/audit only; not usable for invoking calls.
For stream:true (streaming), these headers are not included (or may be empty). This by itself does not imply breach or a mismatch. If verification is needed for streaming traffic, provide the request ID and we will audit via server-side logs and vendor receipts.

​
Security & Retention

We retain for 3 days only:
  • our internal request ID, and
  • the verification response headers listed above.
We do not retain raw vendor api_key values; only masked or one-way forms appear in logs. X-Vendor-Messages-Id is not a secret and cannot be used for authentication or secondary calls. If you use proxies or CDNs, allowlist/preserve X-Vendor-* headers to avoid stripping or rewriting.

​
Non-streaming example

HTTP/1.1 200 OK
Content-Type: application/json
X-Vendor-Messages-Id: msg_7f8e3aa2b9c14d23
X-Vendor-Api-Key: vk_live_****_1a2b_hash_9f12

{"id":"req_123","vendor":"acme","model":"model-x","output":"..."}

​
4) Model Consistency & Mismatch Handling

Consistency Requirement: The vendor field in the response (or metadata) must match the vendor that actually served the request.

​
Mismatch Criteria (any of the following):

  • The response vendor value differs from the actual serving vendor.
  • For stream:false, the verification headers and our routing logs/vendor receipts do not align, absent prior written approval for an exception.

​
Remedy & Compensation

Confirmed “model mismatch” is compensated at 2× the request’s fee (default via credits or bill offsets; cash if required by contract or written agreement). Evidence & Workflow: Provide request ID, timestamps, and the raw response (including headers, if available). We verify using verification headers plus server routing logs and vendor receipts/billing. Missing/Abnormal Headers (non-streaming): If headers are temporarily missing due to vendor limits or maintenance, we will provide equivalent evidence (e.g., vendor receipt IDs, billing records, signed proofs, server logs). If we cannot provide any equivalent evidence within a reasonable timeframe and your materials are complete, the case may be presumed a mismatch and the 2× compensation applies.

​
5) Typical Calls

​
Pinned Vendor

curl https://api.yourouter.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "vendor: openai" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Hello from OpenAI!"}]
  }'

​
Auto Routing

curl https://api.yourouter.ai/v1/chat/completions \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -H "vendor: auto" \
  -d '{
    "model": "gpt-4o",
    "messages": [{"role": "user", "content": "Hello from OpenAI!"}]
  }'

​
6) FAQ

Q: How do I verify streaming responses? A: stream:true does not include verification headers. Open a ticket with the request ID; we will audit via routing logs and vendor receipts. Q: Do you always disclaim responsibility if a vendor is down? A: In Pinned Vendor mode, if the chosen vendor is down, we are not responsible for that request’s unavailability. In Auto mode, if all Authorized Vendors for the model are down, we are likewise not responsible. Q: Does exposing X-Vendor-Messages-Id leak sensitive data? A: No. It is a trace/reconciliation identifier, not a credential. X-Vendor-Api-Key is irreversibly masked.
⌘I