Software Engineering / ENGINEERING CASE STUDY
Third-Party APIs That Misbehave
Stripe webhooks, Microsoft Graph, and an agent-platform vendor API, each handled for how it actually fails: signature checks, replay windows, idempotency, no stored personal data, and verify-after-write.
THE PROBLEM
Build integrations around how APIs actually fail
The challenge
Webhooks get retried and replayed, mailboxes hold sensitive detail, and one vendor API reported success for writes that didn't land. A care SaaS can't afford double-processing or keeping personal data it doesn't need.
My role
How three of the startup's integrations handle that.
What I did
- Stripe webhook: HMAC signature check, a 5-minute replay window, and idempotent processing through a unique index on the event ID. No customer personal data is stored.
- Microsoft Graph: reads a shared mailbox live and stores no email, by design, because clients may send sensitive detail.
- Agent-platform vendor: its API returned 200 with the right echo, but a fresh read served stale data. So every write is verified with an independent re-read.
- Documented 14 vendor bugs and reported them.
The tradeoff
Storing no email means every view is a live Graph call, so it depends on Microsoft being reachable. Holding clients' sensitive detail we don't need would be the worse risk.
THE RESULT
A replayed or retried webhook can't be processed twice, client email never lands in the database, and a vendor's success response isn't trusted until a re-read confirms it.
Stripe webhooks · Microsoft Graph · PostgreSQL · TypeScript
HAVE A SIMILAR CHALLENGE?