Usage, reliability, and data handling
Understand records, tiers, errors, retries, credentials, retention, and offline activation.
Records, tiers and billing cycles
A base record is up to 1.000 Unicode code points per text, rounded up separately for each text, with a minimum of one. The API tier applies its weight to that base count. Fractions are preserved in tenths of a record.
| Tier | Record weight | Native request limit |
|---|---|---|
| Standard | 1,0 | 64 texts · 200.000 code points per text |
| Batch | 0,5 | 200 texts · 200.000 code points per text |
| Real-Time | 1,6 | 4 texts · 4.000 code points per text |
For example, two 800-character texts use 2 Standard records, 1 Batch record or 3,2 Real-Time records. Native Batch is a lower-priority processing tier; asynchronous Azure jobs are a separate request lifecycle.
Plan allowance is used first, then pack records. Monthly allowance resets at the billing boundary and does not roll over. Packs do not expire. An upgrade requires payment and starts a new cycle with the full new allowance; a downgrade or cancellation takes effect at the current period’s end. Review the charge preview in Dashboard before confirming a change.
See consumption in Dashboard or GET /v2/usage. The billing portal provides invoice PDFs, company details and payment methods. Appropriate tax is calculated during checkout and invoices are emailed after purchase.
Errors and retries
Native API errors use {"error":{"code":"…","message":"…","request_id":"…","retryable":false}}. Azure-compatible endpoints use their own error envelopes. Preserve X-Request-Id for troubleshooting.
| Status | Action |
|---|---|
| 401 | Check the key, revocation status and environment. |
| 402 | Add records; the error identifies the required and available amount. |
| 403 | Check whether the plan includes the requested tier. |
| 413 / 422 | Correct the input or split the request within documented limits. |
| 429 | Respect Retry-After, then retry with backoff and jitter. |
| 503 | Temporary service failure. Respect Retry-After when present. |
Validation failures and work rejected before processing do not consume records. A connection loss is not proof that processing failed: keep the request reference and check usage before blindly retrying a large workload. Synchronous results are not stored for replay.
Retry only when retryable is true, and wait for Retry-After when it is present.
Data handling and keys
Direct requests are processed in memory and not stored. A request that names an API session adds its new replacements to that session. Job data and API sessions are kept for a limited time and are encrypted. Usage records contain identifiers, counts and timings, not content. We do not use your content to train models.
Create and revoke API keys in Dashboard. Starter supports one key; higher plans support up to five. Production keys start with shr_live_, sandbox keys with shr_test_. They belong to separate environments. Do not embed them in browser applications, URLs or support messages.
Offline activation
