API Literacy · Level 3
The full picture
Mission briefing
Mission 2-C: Launch is in three days. The integration with the payments provider — the thing that actually charges customers — just started failing intermittently. Sometimes it works. Sometimes it returns nothing. Intermittent is the worst kind.
Our payments integration follows REST — a common set of conventions for how APIs are organized. Predictable addresses, standard verbs like GET and POST. The good news: because it's REST, it behaves the way we expect. So a failure means something specific changed, not chaos.
Look at the logs — we're getting 429s. That's a rate limit. The provider only allows so many requests per minute, and we're knocking too fast. They're not rejecting our data; they're telling us to slow down. Intermittent failure makes sense now — we fail only when we burst.
Separate thing to check: the provider sends us a webhook when a payment settles — they call us, instead of us asking them. If that webhook's payload — the actual data bundle in the message — changed shape, our confirmation screen could break even when the charge succeeded.
So two different mechanisms, two different failure modes. The rate limit explains the intermittent drops. The webhook payload is worth checking for the confirmation screen. I'm not guessing anymore — I'm narrowing.
Payments fail only during high traffic and return a 429. What's the right read?