Integration Patterns

Every Tool Is an Island (Until You Build Bridges)

Your email lives in one tool. Your CRM in another. Your project management in a third. Your analytics in a fourth. Each one is powerful on its own, but the real magic happens when they share data. Integration is bridge-building — connecting islands so information flows freely between them.

The good news: most modern tools are built to connect. The challenge is choosing the right connection pattern for your needs.

Two Integration Models

If you're building workflows that touch more than two services, hub-and-spoke saves you from integration chaos. The hub becomes your command center.

APIs Without the Intimidation

An API is just a structured way for two tools to exchange data. You send a request ("give me all orders from today") and get a response (a list of orders). That's it. The format is usually JSON — which looks scary at first but is really just organized text with labels and values.

Authentication is how APIs know you're allowed to use them. Most use API keys — long strings of characters you include with your requests. Treat them like passwords: never share them publicly, store them securely, and rotate them if they're compromised.

No-Code vs. Custom

Use no-code connectors (Zapier, Make, native integrations) when: the tools already have pre-built connectors, the data mapping is straightforward, and you need to move fast. This covers 80% of integration needs.

Build custom integrations when: you need complex data transformations, the pre-built connectors don't support your use case, you need higher performance or lower latency, or you're hitting rate limits on the no-code platform. This is the 20% that separates good from great.

The Invisible Wall Every Integration Hits

Every API has rate limits — the maximum number of requests you can make in a given time window. Hit the limit and you'll get a 429 error (Too Many Requests). Your workflow needs to respect these limits gracefully, not crash into them.

Know your limits: Before building, check each API's documentation for rate limits. Slack allows 1 message per second per channel. Stripe allows 100 requests per second. OpenAI varies by model and tier. Write these limits down — they're constraints you must design around.

Request batching: Instead of making 100 individual API calls, many services offer batch endpoints. Send all 100 items in a single request. This is faster AND uses less of your rate limit quota.

Token bucket strategy: Process requests at a steady rate just below the limit. If your limit is 100/second, process at 80/second. The 20% buffer prevents bursts from causing failures. Simple and effective.

Retry-After headers: When you do hit a rate limit, most APIs include a Retry-After header telling you exactly how many seconds to wait. Respect it — retrying before the window resets just wastes resources.