BramaPay Docs

Errors & Rate Limits

Handle the stable integration error envelope and throttling safely.

The /v1/invoices API returns errors as:

{
  "error": {
    "code": "INVALID_AMOUNT",
    "message": "Human-readable diagnostic"
  }
}
HTTPCodeMeaning / action
400INVALID_REQUESTFix unknown or invalid fields
400INVALID_AMOUNTSend a valid positive decimal string
400UNSUPPORTED_ASSETUse an enabled asset
400UNSUPPORTED_NETWORKUse an enabled network
400WALLET_NOT_CONFIGUREDAdd a compatible active wallet
401INVALID_API_KEYCheck or rotate the secret key
404INVOICE_NOT_FOUNDCheck the ID and project key
409IDEMPOTENCY_CONFLICTDo not change input under the same key
409PROJECT_NOT_READYComplete project readiness or fund the service balance
429RATE_LIMITEDBack off with jitter, then retry safely
500TEMPORARILY_UNAVAILABLERetry with the same idempotency key

BramaPay applies Redis-backed throttling, but its exact global thresholds are environment configuration rather than a stable public quota. Treat 429 as authoritative, use exponential backoff with jitter, and never create a new idempotency key merely because a request timed out. The public checkout invoice lookup is currently limited to 60 requests per minute; normal checkout already polls at a safe interval.