qua- → sl-.
If you are already calling Quatarly through the OpenAI SDK, this is a four-minute migration. The body shape, the SDK, the exception surface — all unchanged. Three things change: base URL, key prefix, error envelope.
01The three changes, side-by-side
| What | Quatarly | SLASHED |
|---|---|---|
| Base URL | https://api.quatarly.ai/v1 | https://api.slashed.pro/v1 |
| Auth header | X-Quatarly-Token: qua-... | Authorization: Bearer sl-... |
| Key prefix | qua-... | sl-... |
| Error envelope | {"err_code", "err_msg"} | {"error":{"message","type","code","param"}} |
| SDK | Official OpenAI SDK | Official OpenAI SDK (unchanged) |
| Request body | OpenAI v1 spec | OpenAI v1 spec (unchanged) |
| Response body | OpenAI v1 spec | OpenAI v1 spec (unchanged) |
02The five-step migration
Get a SLASHED key.
Sign in at dashboard.slashed.pro. Create a key under Keys → New. Copy the sl-... secret once — it is shown a single time. Optional but recommended: name it migration-from-quatarly and scope it to the model IDs you intend to use.
Swap the env var.
If you have a single env var (e.g. OPENAI_API_KEY, QUATARLY_API_KEY, LLM_KEY) that holds the bearer token, set it to the new sl- value. If you have two env vars (key + base URL), set both.
Update the SDK constructor.
If your code passes base_url / baseURL in source code (rather than via env), update both. The SDK choice does not change — keep the official openai package.
Drop any custom auth-header logic.
If you have code that injects X-Quatarly-Token via a custom HTTP middleware (because the OpenAI SDK does not set that header natively), remove it. SLASHED uses the standard Authorization: Bearer header that the SDK sets for you automatically.
Update any error-parsing code.
If you parse the raw HTTP error body (rather than relying on the SDK's APIError exception class), switch from Quatarly's {"err_code", "err_msg"} envelope to OpenAI's {"error": {"message", "type", "code", "param"}}.
If you only catch the SDK's openai.APIError / RateLimitError / AuthenticationError classes, no change is needed. The SDK maps both envelopes onto the same exception types.
03Model ID mapping
Most Quatarly model IDs map 1:1 to SLASHED. The exceptions are listed below — if your code references a Quatarly-only ID, swap to the closest SLASHED equivalent.
| Quatarly ID | Closest SLASHED ID | Note |
|---|---|---|
| gpt-5.4-mini | gpt-5.4-mini | 1:1 |
| gpt-5.4 | gpt-5.4 | 1:1 |
| gpt-5.5 | gpt-5.5 | 1:1 |
| claude-opus-4.7 | claude-opus-4-7 | Dot → dash in segment |
| claude-sonnet-4.6 | claude-sonnet-4-6 | Dot → dash in segment |
| gemini-3.5-flash | gemini-3.5-flash | 1:1 |
| gemini-3.1-pro | gemini-3.1-pro-preview | SLASHED exposes the preview-tagged ID |
| gemini-2.5-pro | gemini-2.5-pro | 1:1 |
For the full set of valid SLASHED IDs, hit GET /v1/models or see /docs/models.
04Smoke test
Confirm the swap took with a one-line cURL. If you get a 200 with a model reply, you are done.
05Run both side-by-side (optional)
If you want a few days of dual-write before fully cutting over, the cleanest pattern is two SDK clients in the same process. The OpenAI SDK is stateless — instantiating two clients with different base_url / api_key is supported.
06Things that will not change
- Your prompts. Same model, same context, same output distribution.
- Your retry logic. The SDK's default retry on 429/5xx works on both. See /docs/errors §05.
- Your streaming code.
stream=Trueon both, SSE shape is OpenAI-spec on both. - Your tool-use code. Same array shape, same tool-call response surface.
- Your token-counting code, if you use
tiktokenfor OpenAI families.
X-Quatarly-Request-Id header on every response. SLASHED does not document a request-id header today. If your observability layer reads that header, switch to relying on the response body's id field (e.g. chatcmpl-...), which both gateways emit.
07If you get stuck
- Auth error? → See /docs/authentication and /docs/errors §03.
- Unknown-model error? → See /docs/models and the mapping table above (§03).
- Need the dashboard? → See dashboard.slashed.pro for live usage, key management, and per-seat caps.
- Anything weird? → The dashboard ledger shows every request that has reached the gateway, with status, model, and token count.