API Integration Pitfalls in Vibe-Coded Apps

APIs are the connective tissue of modern software. Your app talks to Stripe for payments, Xero for accounting, Google Maps for addresses, Twilio for SMS. A typical business application connects to five, ten, or twenty external services. In a demo, every one of those connections works flawlessly.

The problems start in production. API integrations are not just about making a request and getting a response. They are about handling the hundred ways that request can fail, degrade, or behave unexpectedly. Vibe-coded apps handle approximately none of them.

No Rate Limiting Awareness

Every API has rate limits. Stripe limits you to 100 requests per second. Google Maps has daily quotas. Xero throttles you per minute. These limits are documented, predictable, and completely ignored by AI-generated code.

A vibe-coded app that syncs customer records to your CRM will happily fire off 5,000 API calls in a tight loop. It works perfectly when you test with 10 records. Run it against your real database of 5,000 customers and you hit the rate limit at record 100. The remaining 4,900 silently fail — or the API returns a 429 error your code does not handle and the whole process crashes.

Production integrations implement rate-aware request queuing — spacing out requests, detecting 429 responses, and backing off with exponential delays. This is standard practice. It is virtually nonexistent in vibe-coded apps.

No Retry Logic

APIs fail. Not occasionally — regularly. Network hiccups, server deployments, brief outages. In a well-built system, transient failures are invisible because the system retries automatically.

In a vibe-coded app, a single failed request means a failed operation. The customer clicks “send invoice” and nothing happens. The nightly sync crashes halfway through. A webhook delivery fails and the event is lost forever.

Proper retry logic means exponential backoff with jitter, idempotency checks (so retrying a payment does not charge the customer twice), and dead-letter queues for permanently failed operations. AI tools generate the happy path only: make request, use response. The failure and recovery infrastructure does not exist.

Hardcoded Endpoints and Credentials

This is universal in AI-generated code and creates two serious problems.

First, API URLs and credentials embedded directly in source files. Not environment variables. Literal strings. I have seen vibe-coded apps with Stripe secret keys sitting in frontend JavaScript — visible to anyone who opens browser developer tools.

Second, hardcoded endpoints mean you cannot switch between development and production environments. Your test code talks to your live Stripe account. There is no sandbox. Every test is a live fire exercise.

No Authentication Token Refresh

Most modern APIs use OAuth 2.0. Your app gets an access token that expires after an hour. When it expires, you use a refresh token to get a new one.

AI tools consistently generate code that stores the initial access token and uses it forever. It works in the demo because the demo lasts ten minutes. It works for the first hour of production. Then the token expires and every API call fails silently.

For automated processes that run overnight — data syncs, report generation, scheduled notifications — a failed token refresh means the entire process stops and nobody knows until the morning.

No Webhook Verification

If your app receives webhooks from external services, those webhooks need to be verified. Every reputable API signs its webhooks with a secret, and your application should validate that signature before processing the payload.

Vibe-coded apps almost never verify webhook signatures. Anyone who discovers your webhook endpoint can send fake payloads. A fake “payment successful” webhook could cause your app to ship products that were never paid for. A fake “account deleted” webhook could wipe customer data.

The Compounding Problem

Each of these issues is manageable in isolation. But API integrations rarely fail in just one way. A rate limit triggers a retry that does not exist. The missing retry means a lost record. The lost record creates a data inconsistency between systems. The inconsistency is not detected because there is no reconciliation check. Three months later, your accounting does not match your CRM and nobody knows why.

This is why API integration is one of the highest-risk areas of vibe-coded applications. The failures are silent, cumulative, and only surface long after the damage is done.

What Good API Integration Looks Like

If your vibe-coded app connects to external APIs, here is the minimum for a production implementation:

1. Rate-aware request handling that respects API limits and queues excess requests.
2. Automatic retry with backoff for transient failures, with idempotency checks to prevent duplicates.
3. Credential management through environment variables or a secrets manager, never in source code.
4. Token lifecycle management with automatic refresh before expiry.
5. Webhook signature verification on every incoming webhook.
6. Explicit timeouts on every external call, with appropriate fallback behaviour.
7. Reconciliation checks that periodically verify data consistency across connected systems.

None of this is exotic. It is standard practice in production integrations. Virtually none of it appears in AI-generated code, because none of it is needed for the demo. The demo connects to one API, makes one request, and gets one response. Production connects to ten APIs, makes thousands of requests, and handles the thousand ways those requests can go sideways.

Your prototype proved the integrations are possible. Making them reliable is the next step.