API Integration Anti-Patterns

These are the most common mistakes developers make when integrating APIs. Each one works fine in development but fails in production under real-world conditions.

Daisy Chain Orchestration

Chaining API calls through each other instead of orchestrating from a central point.

The problem: When A calls B calls C calls D, a failure in C is nearly impossible to debug. You cannot retry just the failed step, and you lose visibility into where things broke.

The fix: Use a central orchestrator that calls each service directly and handles failures at each step.

Client-Side Security Calls

Making security-sensitive API calls from browser JavaScript where credentials are visible to anyone.

The problem: API keys are visible in browser DevTools. Anyone can copy your credentials and consume your quota, access your data, or impersonate your application.

The fix: Proxy sensitive calls through your backend. Keep API keys server-side only.

Ignoring Partial Failures

Treating multi-step operations as atomic when each step can fail independently.

The problem: You charge the user, provision access, then the credit step fails. The user paid but cannot use what they bought. Retrying might double-charge them.

The fix: Track state explicitly, implement rollback strategies, and use distributed locks for exactly-once processing.

Why These Patterns Are Dangerous

They share four traits that make them hard to catch:

• They pass in development. The happy path works, so you ship it.
• They fail intermittently. One in a thousand requests breaks. Hard to reproduce.
• They resist diagnosis. Logs do not capture the full picture across services.
• They cascade. One failure triggers more failures downstream.

Read each pattern page for detailed failure scenarios and solutions.