Fragment · Rate Limits

Fragment Dev Rate Limits

Fragment does not publish specific numeric rate limits on its public docs. As a region-scoped GraphQL API used for money movement, callers should expect per-account throttling and should design for idempotent retries: every write mutation carries an idempotency key (ik), so a retried request after a throttle or timeout will not double-post. Specific per-account limits are set by Fragment and are not reconciled in this artifact.

Fragment Dev Rate Limits is the machine-readable rate-limit profile for Fragment on the APIs.io network, conforming to the API Commons Rate Limits specification.

It captures 2 rate-limit definitions, measuring requests and concurrent_writes.

The profile also includes 3 backoff/retry policies defined and response codes documented for throttled.

Tagged areas include Ledger, GraphQL, Rate Limiting, Quotas, and Throttling.

2 Limits Throttle: 429
LedgerGraphQLRate LimitingQuotasThrottling

Limits

Per-Account Request Limit account
requests
see provider documentation
Region-scoped GraphQL endpoint; concrete throttling values are not published.
Write Concurrency ledger
concurrent_writes
see provider documentation
Concurrent postings to a ledger; use idempotency keys so retries are safe.

Policies

Idempotent Retries
Every write mutation (addLedgerEntry, reconcileTx, syncCustomAccounts, syncCustomTxs, createLedger, storeSchema, reverseLedgerEntry) accepts an idempotency key. Retry the same request with the same key to recover from a throttle, timeout, or network error without double-posting.
Backoff Strategy
Clients should implement exponential backoff with jitter on 429 / 5xx and honor any Retry-After header.
Short-Lived Tokens
OAuth2 client-credentials access tokens expire in about 1 hour; cache and refresh tokens rather than minting one per request.

Sources