Building APIs That Survive Production: Lessons from 3 Projects

The Thesis

After building APIs for SpendWise (AI finance), Srimaccafes (e-commerce payments), and TechSympo (real-time game), patterns emerged. The projects are different, but the API challenges — reliability, idempotency, error handling — are the same.

Idempotency Is Not Optional

Srimaccafes taught me this lesson. Razorpay fires webhooks with at-least-once delivery. Without idempotency, a single payment creates duplicate orders, duplicate inventory deductions, and duplicate customer emails.

The fix is simple: maintain a processed-keys store. Before processing any operation, check if that operation's unique key has been processed. If yes, return success without action. If no, process and mark.

This applies to:

• Payment webhooks (order_id as key)
• Form submissions (submission_id as key)
• API retries (idempotency-key header)

Validation Layers Save Lives

SpendWise's AI pipeline taught me that upstream output is never guaranteed. Google Gemini can hallucinate categories, invent currencies, or produce malformed JSON. Every API that consumes external or AI-generated data needs a validation layer that:

1. Checks structural correctness (required fields present, correct types)
2. Checks semantic validity (values within expected ranges)
3. Provides clear error messages when validation fails

Real-Time Requires Fallbacks

TechSympo taught me that real-time features need offline fallbacks. The live scoreboard worked via WebSockets, but I also had a manual refresh button and a paper score sheet. When the network glitched, the game continued.

The rule: if your feature breaks in front of an audience, you need a backup that works without it.

Final Thought

Production APIs are not about the happy path. They are about what happens when everything goes wrong — duplicate requests, crashed services, corrupted data — and the system still produces correct results.