Support

Support is email-based. One channel:

[email protected]

There is no live chat, phone line, or ticket portal today.

What to include in a ticket

Send us:

1. The X-Request-Id header from the failing response. (Every response carries one. It mirrors the request_id field on a sync response.)
2. The HTTP status code and the response body, if any.
3. The approximate timestamp in UTC.
4. Your account email and plan tier.
5. A one-line description of what you expected versus what you got.

With the request_id we can locate the exact call, the rate-limit state, the mode, the cost_units charged, and the upstream provider's status - without needing the prompt or completion content.

What not to include

• Your full API key. We see the prefix in logs already; we do not need the full secret. If you accidentally pasted one, revoke it from the dashboard and mint a new one.
• The full prompt or completion content unless the issue is prompt-specific and you've cleared the content for sharing. The request_id is enough on our side.
• Customer PII. Same reasoning - request_id resolves the call without it.

Response targets

If you're on Enterprise and the issue is production-impacting, mention that explicitly in the subject so it's routed correctly.

Subject-line conventions

Prefix the subject so the message routes quickly:

Vulnerability disclosure

Same email, subject vulnerability: .... We acknowledge within one business day. Full policy on the Security page.

Status & incidents

Live uptime and incident history live on the status page. For incidents that affect a broad surface, we also post a note in the Changelog and reply on open tickets. If you suspect an ongoing incident, send a short email - no request_id needed; we'll correlate on our side.

Sales

Custom quotas, dedicated support, and contractual SLAs are negotiated over email. Same address, subject enterprise: ..., and a sentence about your expected volume.

Related