Atomic · Rate Limits

Atomic Fi Rate Limits

Atomic does not publish specific public rate-limit numbers for its UserLink and PayLink APIs. Limits are applied per account/credential and negotiated as part of the enterprise agreement. Backend endpoints are authenticated with API Key + Secret and are expected to be called from a server, not the client. Task processing is asynchronous - work is queued and completion is signaled via task status and webhooks rather than synchronous request rate. Specific per-endpoint values are not reconciled in this artifact.

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

It captures 3 rate-limit definitions, measuring requests, tasks, and deliveries.

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

Tagged areas include Fintech, Payroll, Financial Connectivity, Rate Limiting, and Quotas.

3 Limits Throttle: 429
FintechPayrollFinancial ConnectivityRate LimitingQuotasThrottling

Limits

Backend API Requests account
requests
see provider agreement
Per-credential limits set by contract; API Key + Secret required.
Task Processing account
tasks
asynchronous / queued
Tasks are queued and processed async; poll status or use webhooks.
Webhook Delivery endpoint
deliveries
retried up to 3 times, 30s apart
Failed webhook deliveries are retried up to three times at 30-second intervals; manual replay available.

Policies

Server-Side Credentials
API Key and Secret must be used from a backend service, never exposed to client-side apps; clients use short-lived public tokens instead.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on 429 responses.
Async by Design
Prefer webhooks (task-status-updated, payroll-data-fetched) over aggressive polling to stay within limits.

Sources