Migration

Move an existing OpenAI-compatible client to Keiro by changing three explicit inputs: base URL, credential source, and model ID. Keep request and response handling on a documented public surface.

On this page 1 of 6

Change the base URL#

Use the public /v1 base once in the client constructor:

Text

https://api.keirolabs.ai/v1

Do not append another /v1, use a raw origin, or mix public and internal endpoints in one client.

Change authentication#

Create a workload-specific Keiro key in the console and resolve it through your approved secret store. Do not reuse an external provider key and do not put the Keiro secret in source, URLs, shared environment files, or logs.

See API keys for the lifecycle and SDKs for safe constructor examples.

Change the model ID#

Start with eb1-preview and use GET /v1/models to confirm access. Do not send raw provider model IDs or private route names. See Models for the four public paid-beta IDs.

Choose the matching API surface#

Compatibility is strict where documented. Remove unsupported parameters rather than assuming they will be ignored. In particular, JSON mode and JSON Schema structured output are not currently supported, while function tools have their own documented contract.

Existing chat.completions client: keep the message-array request and use Chat Completions.
Existing Responses client: use Responses.
Existing Messages client: use Messages and its documented field subset.

Migration checklist#

Create a dedicated Keiro key.
Replace the client base URL.
Pass the Keiro key from an approved credential source.
Replace the model ID with an account-enabled public eb1 ID.
Run one buffered request and assert the documented text field.
If used, test streaming terminal and error behavior.
If used, test every tool and image workflow rather than only a text prompt.
Add 429 and transient 5xx handling that honors Retry-After.
Add an idempotency key to retry-sensitive operations.
Compare Usage and Logs before moving production traffic.