Service levels
These are the objectives we run the production API to, measured from our side, per calendar month. Contracts for data products may give credits against them; the contract says so where it does.
| Objective | Target | Measured as |
|---|---|---|
Availability of /v1 and /mcp | 99.9% | Share of requests not answered with 5xx |
| Read latency | 95% under 800 ms | GET requests under /v1, at our edge |
| Webhook first attempt | 99% within 60 s | From the event being recorded to the first attempt to your endpoint |
| Revocation | within 60 s | A revoked key or token stops working everywhere (at once for actions and organization records) |
| Deprecation notice | at least 12 months | See versioning |
Not counted against the objectives:
- Answers caused by the request:
4xx, including429for rate limits and quotas. 503answers with a partner's code (escrow_unavailable,credit_unavailable, ...) while that partner is down. We tell you which partner and when it is back.- Your webhook endpoint failing or answering slowly. Retries follow the webhook schedule.
- The sandbox, which is not offered yet; once it runs, it is run on a best-effort basis.
- Maintenance announced at least 7 days ahead, at most 4 hours a month, outside 06:00 to 22:00 Türkiye time.
When something goes wrong
- Incidents that affect the API are posted on the status page as they happen, with updates at least every hour until resolved.
- Data products customers are told directly, by the contacts in their contract.
- A post-incident report follows within 5 working days for any incident that used more than a quarter of the month's error budget (about 11 minutes of full outage).
Your side
Retry 5xx and 429 with backoff and jitter. Keep webhook handlers fast and idempotent. Log X-Request-Id: with it we can trace any request you ask about.