Thanx · Rate Limits

Thanx Rate Limits

Thanx publishes global, numeric, hard rate limits: 5 requests per second and 2,000 requests per 15 minutes, enforced with 429 Too Many Requests. This CORRECTS the previous revision of this artifact (2026-06-03), which recorded "not published" — the limits now appear on the Partner API overview and in the campaign/subscriber integration guides. Thanx documents the numbers and the retry strategy but publishes NO rate-limit response headers, so a client cannot read its remaining budget at runtime and must rely on catching the 429 and backing off. Higher throughput is available by request through developer support.

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

It captures 5 rate-limit definitions, measuring requests_per_second, requests_per_window, identifiers_per_request, codes_per_request, and seconds.

The profile also includes 6 backoff/retry policies defined and response codes documented for badRequest, unauthorized, forbidden, notFound, tooManyRequests, and unprocessable.

Tagged areas include Rate Limiting, Loyalty, Guest Engagement, and Restaurant.

5 Limits
Rate LimitingLoyaltyGuest EngagementRestaurant

Limits

Global request rate (per second) per-credential
requests_per_second
5
"Integration partners should not exceed a rate of 5 requests per second ... These default rate limits are hard-limits and APIs will return 429 Too Many Requests once these limits are crossed."
Global request volume (per 15 minutes) per-credential
requests_per_window
2000
Applies alongside the per-second ceiling; both are enforced.
Reward issuance batch size (Partner API) per-request
identifiers_per_request
10000
Submit campaign reward identifiers in batches of up to 10,000 per request to POST /partner/campaigns/issue. Per-user requests are explicitly called out as "significantly less efficient and may result in rate limiting under the global rate limits". Issuance is asynchronous via an issuance job.
Promotion code generation batch size per-request
codes_per_request
100000
1–100,000 codes per generate-codes request; exceeding it returns 422 Unprocessable Entity. Up to 4,000,000 codes may be requested via code_count at promotion creation.
Partner access token lifetime token
seconds
3600
Privileged end-user access tokens accept an optional expires_in between 60 and 3600 seconds. Not a rate limit; recorded here because it bounds retry windows.

Policies

Exponential backoff on 429
"Rate-limited API requests can and should be retried. One such strategy to handle this is through an exponential backoff strategy."
Request an increase
Integrations needing higher throughput email developer.support@thanx.com to request an increase to the default values. Limits are therefore per-credential defaults, not a platform ceiling.
Batch over loop
Prefer batched reward issuance (up to 10,000 identifiers per request) over issuing rewards one at a time; this is the documented mechanism for staying under the global limits.
Asynchronous processing
Reward issuance returns 202 Accepted with an issuance job; poll getIssuanceJob or consume the reward_batch.completed webhook rather than blocking or polling tightly.
Pagination
Collection endpoints (rewards, purchases, locations, campaigns, users) return a pagination object (total_page, per_page, current_page); page through results instead of requesting large pages.
Do not poll in production
Sandbox purchase ingestion is slow enough that Thanx documents a backoff polling recipe, but explicitly states production integrations should not poll — sandbox latency is a sandbox artifact.

Sources