APIs & Connectivity includes four patterns: REST APIs for on-demand HTTP requests (33,100 monthly searches), GraphQL for flexible queries where clients request exactly what they need, inbound webhooks for receiving real-time events from external systems, and outbound webhooks for pushing events to subscribers. REST APIs are simplest and most universal. GraphQL reduces over-fetching. Webhooks eliminate polling. Most integrations combine REST for lookups with webhooks for real-time events. The right choice depends on who initiates the data flow.
Your CRM has customer data. Your billing system has payment data. Your support tool has ticket history. Your reporting dashboard needs all three.
You built integrations. They worked. Then an API changed, a webhook stopped firing, and now data flows... sometimes.
You spend more time keeping systems connected than using the data they share.
Systems that cannot talk to each other might as well not exist.
Part of Layer 0: Foundation - The bridges everything else depends on.
APIs & Connectivity is about the bridges between systems. REST APIs let you request data on demand. GraphQL lets clients ask for exactly what they need. Webhooks push updates the moment something happens. The right choice depends on who initiates, how much control you have, and whether you need real-time updates.
Most real integrations use multiple patterns. REST APIs for on-demand lookups, webhooks for real-time notifications. The question is not "which one?" but "which pattern for which data flow?"
Each connectivity pattern optimizes for different data flow needs. Choosing wrong means polling when you could push, or waiting when you need instant updates.
REST | GraphQL | Inbound Webhooks | Outbound Webhooks | |
|---|---|---|---|---|
| Who Initiates | You ask for data when you need it | You ask for data when you need it | External system pushes to you | You push to external system |
| When Data Flows | On demand when you call the endpoint | On demand when you run a query | Immediately when event occurs externally | Immediately when event occurs in your system |
| Data Flexibility | Fixed endpoints return fixed data shapes | Query exactly the fields you need | Receive whatever the sender sends | You define the payload shape |
| Complexity | Simple HTTP, universally understood | Schema setup, resolver logic, query complexity | Signature verification, idempotency, retries | Queue management, retry logic, failure handling |
The right choice depends on who controls when data moves and how fresh it needs to be. Answer these questions to find your starting point.
“I need to fetch data from an external service when my code runs”
REST APIs are the universal language for on-demand data requests.
“Different parts of my app need different fields from the same data”
GraphQL lets each client ask for exactly what it needs in one request.
“I need to know the moment something happens in an external service”
Inbound webhooks push events to you in real-time without polling.
“External systems need to know when events happen in my system”
Outbound webhooks push your events to subscribers instantly.
“I need real-time sync between my system and external services”
Use inbound webhooks to receive, outbound to send, REST for initial sync.
Answer a few questions to get a recommendation.
Connectivity is not about specific technologies. It is about letting information flow where it needs to go, when it needs to get there.
One system has information another system needs
Establish a communication channel with clear contracts
Data flows reliably without manual intervention
When a payment succeeds and three systems need to know immediately...
That's a webhook problem - the payment processor pushes the event, your system receives it, then pushes to the others.
When the dashboard needs data from five different tools...
That's a REST API aggregation problem - pull from each source, combine, present. Or GraphQL if each view needs different fields.
When something important happens and your team chat should know about it...
That's an outbound webhook problem - event occurs, webhook fires, team channel gets notified.
When a form submission needs to trigger a multi-step workflow...
That's an inbound webhook triggering an orchestration - external system pushes event, your system reacts.
Where is data stuck in one system when another system needs it?
These mistakes seem minor in development. They become major in production.
Move fast. Structure data “good enough.” Scale up. Data becomes messy. Painful migration later. The fix is simple: think about access patterns upfront. It takes an hour now. It saves weeks later.
REST APIs use fixed endpoints that return predetermined data structures. You call /customers and get all customer fields. GraphQL uses a single endpoint where clients specify exactly which fields they need. REST is simpler to implement and universally understood. GraphQL reduces over-fetching and under-fetching but requires schema design and has security considerations around query complexity.
Use webhooks when you need to react to events immediately without constantly polling. REST APIs require you to ask "did anything change?" repeatedly. Webhooks push notifications to you the moment something happens. Use REST for on-demand data lookups. Use webhooks for real-time event notifications like payment confirmations, form submissions, or status changes.
A webhook is an HTTP callback that sends data to your server when an event occurs in another system. You provide a URL endpoint. When something happens (like a payment succeeding), that system sends a POST request to your URL with event details. Your server receives it, verifies authenticity, and processes the data. It is push-based rather than pull-based.
Inbound webhooks receive events from external systems. You expose an endpoint, they call it when something happens. Your payment processor sends you payment notifications. Outbound webhooks send events to external systems. Something happens in your system, you call their endpoint. You notify your team chat when an order ships. Most integrations use both: receiving events from some systems, sending to others.
Yes, this is the most common pattern. Use REST APIs for initial data sync and on-demand lookups when your code needs information. Use webhooks for real-time event notifications so you react immediately when something changes. For example: REST to fetch customer data when loading a page, webhooks to know instantly when that customer makes a purchase.
For inbound webhooks: always verify signatures to confirm the sender is authentic. Handle retries without processing the same event twice (idempotency). Keep endpoints private but accessible. For outbound webhooks: sign your payloads so receivers can verify authenticity. Implement retry logic with exponential backoff. Never send sensitive data to unverified endpoints.
Common mistakes include: ignoring rate limits until you get blocked, processing webhooks synchronously causing timeouts and duplicate processing, skipping signature verification which allows fake events, not implementing retries when calls fail, hardcoding credentials in code instead of environment variables, and building N+1 query problems in GraphQL resolvers.
Ask: Who initiates the data flow? How fresh does data need to be? If you control timing and on-demand is fine, use REST. If you need flexible queries for different clients, consider GraphQL. If external systems should notify you instantly, use inbound webhooks. If you should notify others instantly, use outbound webhooks. Most real integrations combine multiple patterns.
GraphQL is a query language for APIs that lets clients request exactly the data they need in a single request. Use it when different clients (mobile, web, partners) need different data shapes from the same source, when you want to reduce round trips, or when over-fetching is a problem. It requires more setup than REST and needs query complexity limits to prevent abuse.
Most REST APIs use one of three patterns: API keys passed in headers for simple authentication, OAuth tokens for delegated access on behalf of users, or Bearer tokens in Authorization headers. The API documentation specifies which method to use. Always store credentials in environment variables, never in code. Rotate keys periodically and use different keys for different environments.
Have a different question? Let's talk