Got Feedback?

Tell us how we can make Lunch Flow more useful to you.

Planned

Document rate-limit handling and implement Retry-After headers

When GoCardless (or other providers) rate-limits Lunchflow's API calls, we currently return a 503 with the message "Bank data is temporarily unavailable. This usually resolves within a minute." Without documented retry semantics, client integrations have no spec to work from. Two concrete asks: Document in the API docs how clients should handle 503 responses from Lunchflow when upstream rate limits are hit, including recommended retry windows. Implement a Retry-After header in the response so integrations can handle retries correctly without guessing. Context: this surfaced because all self-hosted Sure instances default to syncing at 02:22 UTC, creating a thundering herd that hits GoCardless's 100 req/min cap.

Stephen about 2 months ago

💡 Feature Request