Third-Party Integrations via CLI

You need to integrate Stripe for payments by Thursday. The docs are thorough but sprawling — webhooks, idempotency keys, checkout sessions, customer portal, subscription billing, proration, tax calculation. You copy the quickstart example, get a basic charge working, and then spend the next two days handling edge cases: failed webhooks, duplicate events, expired sessions, currency mismatches. Every payment provider, email service, and OAuth provider has the same story: the happy path takes an hour, the production-ready integration takes a week.

What You’ll Walk Away With

• A Claude Code workflow for generating production-quality API integrations including error handling, retry logic, and webhook verification
• Copy-paste prompts for Stripe, Resend/SendGrid, OAuth 2.0, and webhook processing that produce code you can ship, not just demo
• An MCP server strategy that gives Claude Code direct access to third-party API documentation during generation

Building a Complete Payment Integration

The difference between a demo integration and a production one is error handling, idempotency, and webhook reliability. Claude Code generates all three when you describe the full requirements.

Tip

Copy-paste prompt — Stripe integration with webhooks:

Build a complete Stripe payment integration for our Express API. Include: 1) a checkout session endpoint that creates a Stripe Checkout session with line items from our cart, supports both one-time and subscription billing, and includes metadata with our internal order ID, 2) a webhook handler at /api/webhooks/stripe that verifies the signature using STRIPE_WEBHOOK_SECRET, handles checkout.session.completed, invoice.payment_failed, and customer.subscription.deleted events, stores a webhook_events table for idempotency (skip events already processed), 3) error handling that distinguishes between Stripe API errors, network errors, and our own application errors, 4) a retry mechanism for failed webhook processing. Use our existing database connection and put the Stripe logic in a services/stripe.ts file.

Claude Code generates a well-structured integration because the prompt specifies the exact events, the idempotency strategy, and the error categories. Without these details, you would get a happy-path-only implementation.

After generation, verify the webhook handling locally:

# Install the Stripe CLI for local webhook testing
stripe listen --forward-to http://localhost:3000/api/webhooks/stripe

# In another terminal, trigger a test event
stripe trigger checkout.session.completed

Then ask Claude Code to handle the edge cases:

The webhook endpoint works for successful payments. Now handle these edge cases: 1) duplicate webhook delivery (Stripe sends the same event twice), 2) webhook arrives before the checkout session redirect completes (race condition), 3) the customer's subscription payment fails and we need to send a dunning email via Resend, 4) a refund is issued and we need to update our order status.

Email Service Integration

Email integrations look simple until you handle templates, attachments, bounce handling, and rate limits.

Tip

Copy-paste prompt — transactional email service:

Create an email service module (services/email.ts) using Resend as the provider. Include: 1) a typed sendEmail function that accepts to, subject, template name, and template variables, 2) email templates stored as React Email components in emails/ directory for: welcome, password-reset, order-confirmation, and payment-failed, 3) rate limiting (max 10 emails per second to stay within Resend's limits), 4) a queue mechanism that retries failed sends up to 3 times with exponential backoff, 5) a development mode that logs emails to console instead of sending. The RESEND_API_KEY comes from an environment variable.

The rate limiting and retry logic are what separate a production integration from a tutorial example. Claude Code generates both because the prompt asks for them explicitly.

OAuth 2.0 Integration

OAuth is a protocol that everyone implements slightly differently. Claude Code handles the nuances of each provider.

Implement OAuth 2.0 login with Google and GitHub for our Express app. For each provider: 1) create the authorization URL with correct scopes (email and profile for Google, user:email for GitHub), 2) handle the callback route that exchanges the code for tokens, 3) fetch the user's profile and email, 4) create or link the user account in our database (match by email), 5) issue our own JWT session token, 6) handle the case where the user denies access, 7) handle the case where the user's email already exists with a different auth provider. Store client IDs and secrets in environment variables. Support both a web redirect flow and a mobile flow that returns the token in the URL fragment.

Note

Claude Code generates provider-specific code because Google and GitHub have different token endpoints, different profile endpoints, and different scopes. Rather than using a generic OAuth library that abstracts away the differences, the generated code handles each provider’s quirks directly, which makes debugging much easier.

Webhook Processing Architecture

As you integrate more services, webhook handling becomes a system of its own. Claude Code can generate a robust webhook processing architecture.

Tip

Copy-paste prompt — webhook processing system:

Create a generic webhook processing system that handles webhooks from Stripe, GitHub, and our payment provider. Include: 1) a router that dispatches to the correct handler based on the webhook source (identified by URL path or header), 2) signature verification for each provider (Stripe uses stripe-signature header, GitHub uses x-hub-signature-256), 3) an event store (webhook_events table) that records every incoming webhook with timestamp, source, event type, payload, and processing status, 4) idempotent processing (check event ID before handling), 5) a dead letter queue for events that fail processing after 3 retries, 6) an admin endpoint that lists recent webhook events with their status for debugging.

This system grows with you. When you add a new integration, you just add a new handler and signature verifier to the existing framework.

Using MCP Servers for API Context

MCP (Model Context Protocol) servers can give Claude Code direct access to third-party API documentation, making integrations more accurate.

# Add the official Stripe MCP server
claude mcp add stripe -- npx -y @stripe/mcp

# Now Claude Code can reference current Stripe API docs while generating code

With MCP configured, your prompts can be less detailed because Claude Code can look up the correct endpoint paths, parameter names, and response formats:

Using the Stripe API docs, create an endpoint that lets customers update their subscription's plan. Handle proration automatically and send a confirmation email with the new billing amount.

Generating API Client Wrappers

Rather than using third-party SDKs (which add bundle size and version coupling), Claude Code can generate typed API clients.

Generate a typed HTTP client for the SendGrid v3 API. Cover these endpoints: send email, create contact list, add contacts to list, get email statistics. Use fetch (no external HTTP library). Include TypeScript types for all request/response bodies based on their API documentation. Add request/response logging at debug level and error handling that throws typed errors with the SendGrid error code and message.

This gives you a thin, typed client that you fully control — no SDK updates to manage, no bundle bloat, and easy to debug because the HTTP calls are visible.

When This Breaks

Webhook signature verification fails in production but works locally. The most common cause is a load balancer or reverse proxy that modifies the request body before your handler sees it. Stripe signature verification requires the raw body, not a parsed JSON body. Ask Claude Code: “Update the webhook endpoint to use the raw request body for signature verification. Our Express app uses express.json() which parses the body before our handler runs.”

OAuth callback returns a 500 after successful authorization. Usually a missing error handler on the token exchange step. Feed the error to Claude Code: “The Google OAuth callback throws this error after the user authorizes. The authorization code is valid but the token exchange fails. Debug the issue.”

Webhook events arrive out of order. Stripe might send invoice.payment_succeeded before checkout.session.completed. Your handlers need to be order-independent. Ask Claude Code: “Refactor our webhook handlers to be idempotent and order-independent. Each handler should check the current state of the resource and only process the event if the state transition is valid.”

The API rate limit is hit during a batch operation. When importing 10,000 contacts into SendGrid, you cannot fire 10,000 requests simultaneously. Claude Code generates rate-limited clients, but verify: “Add a concurrency limiter to our SendGrid client that sends at most 5 requests per second and queues the rest.”

What’s Next

Security Auditing Verify that your integrations handle secrets safely and validate all incoming data

Task Automation Automate multi-service workflows like order processing pipelines

Monitoring and Observability Monitor your third-party integrations for failures and latency