MyFatoorah · Rate Limits

Myfatoorah Rate Limits

MyFatoorah does not publish fixed numeric per-endpoint rate limits. The documentation explicitly notes that the GetPaymentStatus inquiry endpoint is rate limited and advises contacting support when sending many requests in a short window, and recommends inquiring by PaymentId rather than polling aggressively. Practically, callers should treat the API as rate-limited, implement backoff, and rely on webhook callbacks for payment/refund status changes instead of tight polling loops.

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

It captures 2 rate-limit definitions, measuring requests.

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

Tagged areas include Payments, Payment Gateway, Rate Limiting, and Quotas.

2 Limits Throttle: 429
PaymentsPayment GatewayRate LimitingQuotas

Limits

GetPaymentStatus Inquiries account
requests
rate limited (numeric cap not published)
Docs warn against high-frequency status polling; inquire by PaymentId and use webhooks.
General API Requests account
requests
not published
No fixed numeric per-endpoint request-rate limit is documented.

Policies

Prefer Webhooks
Use MyFatoorah HTTP POST webhook callbacks for transaction and refund status changes instead of polling GetPaymentStatus.
Backoff Strategy
Implement exponential backoff with jitter and honor Retry-After on 429 responses.
Idempotent Inquiry Keys
Query status by stable keys (PaymentId, InvoiceId, CustomerReference) to avoid redundant calls.

Sources