Pomelo · Rate Limits

Pomelo Rate Limits

Pomelo (pomelo.la) secures its REST API with OAuth 2.0 client-credentials Bearer tokens and applies per-client protections against abuse. Public, per-endpoint request quotas are not published; effective limits are set per program. Operationally significant is the real-time authorizer: when Pomelo POSTs an authorization to the client's endpoint, the client must validate the signature and return a signed approve/reject response within the card network time window, or the transaction is rejected. Bulk operations are bounded (innominated card batches are capped at 1,000 cards each, with bulk batch creation limited per request). Specific numeric per-endpoint limits are not reconciled in this artifact.

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

It captures 5 rate-limit definitions, measuring requests, milliseconds, cards, batches, and items.

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

Tagged areas include Fintech, Card Issuing, Embedded Finance, Payments, and Latin America.

5 Limits Throttle: 429
FintechCard IssuingEmbedded FinancePaymentsLatin AmericaRate LimitingQuotasThrottling

Limits

API Requests client
requests
see provider documentation
Per-client REST request limits are program-specific and not publicly published.
Authorizer Response Window transaction
milliseconds
card network time window
Synchronous authorizer callback must return a valid signed response within the network-imposed window or the transaction is rejected.
Card Batch Size request
cards
1000
Maximum innominated cards per batch via POST /cards/v1/batches.
Bulk Batches request
batches
15
Up to 15 batches (1,000 cards each) per bulk batch-creation request.
Pagination request
items
see provider documentation
List endpoints are paginated via page[size] and page[number].

Policies

Signed Authorizer Responses
Clients must validate the inbound signature and sign the response body with the timestamp and response endpoint using their api-secret; mismatched or expired signatures cause the transaction to be rejected.
Backoff Strategy
Clients should implement exponential backoff with jitter and honor Retry-After on 429 responses.
Idempotency
Use idempotency keys on create operations to avoid duplicate cards, users, or transfers on retries.

Sources