AI Tool Pipelines — Automate Your WorkflowsAI Tool Pipelines

API pipelines

API integration patterns that survive real traffic: webhooks, retries, idempotency, rate limits, queues. Written for developers who have been burned at least once.

Key takeaways

  • Idempotency keys ship BEFORE retry logic. Always. The cost of forgetting once is duplicate charges, refund work, and lost trust.
  • Move any work over 2 seconds into a background queue + job-status endpoint. Synchronous HTTP dies at the platform timeout.
  • Use exponential backoff with jitter on retries. Lockstep retries from a thousand clients create thundering herds that take services down.
  • Always log the full (request, response, status) tuple to Postgres. Webhook providers WILL ship breaking changes silently.

Frequently asked questions about this category

What is the difference between a webhook and an API call?

A webhook is an inbound HTTP POST from a third party when an event happens (Stripe charge succeeded, Shopify order placed). An API call is an outbound HTTP request you make to read or change data. Most pipelines combine both: a webhook fires, your handler makes API calls to enrich and route.

How do I make a webhook handler idempotent?

Take the event ID from the payload (Stripe, GitHub, Shopify all include one), store it in a deduplication table or Redis SET with a 24–hour TTL, and short-circuit if you have already processed it. Without this, replays and retries double-charge or duplicate downstream work.

When should I use a queue (BullMQ, SQS, Inngest) vs direct processing?

Direct processing for anything that completes in under 2 seconds and tolerates inline retries. A queue for anything past that: long-running LLM calls, PDF generation, third-party API chains. Queues isolate slowness and let you scale workers independently.

How do I rate-limit my own API without losing legitimate users?

Sliding-window in Redis (or Upstash Ratelimit), keyed by API key not IP, tiered by plan. Return HTTP 429 with a Retry-After header. Never silently drop requests — well-behaved clients can only back off if you tell them to.

What is the most common API integration mistake?

Trusting that the third party will never send a duplicate webhook. They will. Every webhook handler must be idempotent by event ID, or your first replay storm will create chaos in your database.