The integration question changes shape every few years[/HEADING>
"How do we connect system A to system B" used to mean "write some PHP that polls system B's database every five minutes". It now means choosing among webhooks, REST APIs, GraphQL, message queues, iPaaS platforms, and a half-dozen vendor-specific eventing systems. The patterns below are what we apply to keep integrations from becoming tomorrow's mess.
Webhooks: the modern default[/HEADING>
A webhook is "system A makes an HTTP POST to system B when something happens". They're now table stakes for any modern web platform.
What works:
- System B exposes a stable URL
- System A signs the payload (HMAC-SHA256 typically)
- System B verifies the signature, processes asynchronously, returns 200
- System A retries on 5xx with exponential backoff
What goes wrong:
- No signature verification — anyone can send fake events
- Synchronous processing in the webhook handler — slow handler causes timeouts and retries
- No idempotency — duplicate events processed twice (inevitable; design for it)
- No replay capability — events lost during system B downtime are lost forever (unless system A supports replay)
REST APIs: the workhorse
For pull-style integration, REST is the default. Modern patterns:
- Versioned endpoints (URL path or header)
- OAuth 2.0 / API key auth
- Pagination via cursor (not offset — drift on changing datasets)
- Rate limit headers (X-RateLimit-Remaining, X-RateLimit-Reset)
- Conditional requests (ETag / If-None-Match) for cache efficiency
- Webhook + REST in tandem — webhook to know about changes, REST to fetch detail
GraphQL: a niche where it shines (over-fetching reduction, polymorphic clients), more complex everywhere else. Default to REST unless you have a specific reason.
iPaaS: when to lean on it[/HEADING>
"Integration Platform as a Service" — Zapier, Make, n8n, Pipedream, Workato. They abstract the integration layer.
When iPaaS makes sense:
- Cross-platform integrations between mature SaaS products
- Customer / business-team-driven integrations (don't require dev work)
- Low to moderate volume
- Time-to-value matters more than long-term cost
When it doesn't:
- High volume (cost / latency become problems)
- Custom logic that exceeds the iPaaS's flow capability
- When the integration is mission-critical (debug story is harder)
n8n in particular has emerged as a viable self-hostable option in 2026 — open-source, Docker-deployable, 400+ integrations. We use it for internal automations where the alternative would be Zapier at $200/month.
Message queues: when you need decoupling[/HEADING>
For internal architecture (not external integrations), message queues are how systems decouple:
- RabbitMQ — mature, AMQP, complex routing
- Redis Streams / Kafka / Pulsar — high-throughput log-style
- NATS / NATS Jetstream — lightweight, modern, simpler than Kafka
- SQS / SNS / EventBridge — AWS-native equivalents
For "integrate WHMCS with XenForo" — too heavy. For "process incoming user events at scale" — appropriate.
The integration design checklist[/HEADING>
Before building any integration:
- What's the source-of-truth? One side must own each entity.
- What's the latency tolerance? Real-time, near-real-time, eventual?
- What's the failure mode? If the integration is down, what works / breaks?
- How do you debug a missing or duplicated event in production?
- How do you replay events after an outage?
- How do you migrate when the integration evolves?
Common patterns across web platforms[/HEADING>
- WHMCS → XenForo — webhook on order/upgrade, sync user role/group; the AIOR-style use case
- Stripe → backend — webhook on payment events, with signature verification
- Mailchimp → CRM — webhook on subscribe/unsubscribe; iPaaS often the easiest path
- E-commerce → ERP — heavier integration, often custom; consider message queue or middleware
- Form submissions → multiple destinations — server-side fan-out via webhook listeners or iPaaS
Avoiding vendor lock-in in integrations[/HEADING>
- Abstract vendor-specific clients behind your own interface
- Your business logic lives in your code, not in the iPaaS flow
- Document the integration so it can be rebuilt if the iPaaS goes away
- Avoid features unique to a single vendor unless they're load-bearing
One pattern we'd warn about[/HEADING>
Building integration logic into your application's main code path. The integration becomes part of the critical path; failures cascade. Decouple via webhooks + queues + retries.
One pattern that always pays off[/HEADING>
Logging every webhook in / out, with full payload and signature, retained for 30+ days. The day you need to debug "did Stripe send us this event" is the day you'll wish you had this log.
What's your integration stack? And — for the iPaaS folks — has the build-vs-buy line moved over the last year, in either direction?
A webhook is "system A makes an HTTP POST to system B when something happens". They're now table stakes for any modern web platform.
What works:
- System B exposes a stable URL
- System A signs the payload (HMAC-SHA256 typically)
- System B verifies the signature, processes asynchronously, returns 200
- System A retries on 5xx with exponential backoff
What goes wrong:
- No signature verification — anyone can send fake events
- Synchronous processing in the webhook handler — slow handler causes timeouts and retries
- No idempotency — duplicate events processed twice (inevitable; design for it)
- No replay capability — events lost during system B downtime are lost forever (unless system A supports replay)
REST APIs: the workhorse
For pull-style integration, REST is the default. Modern patterns:- Versioned endpoints (URL path or header)
- OAuth 2.0 / API key auth
- Pagination via cursor (not offset — drift on changing datasets)
- Rate limit headers (X-RateLimit-Remaining, X-RateLimit-Reset)
- Conditional requests (ETag / If-None-Match) for cache efficiency
- Webhook + REST in tandem — webhook to know about changes, REST to fetch detail
GraphQL: a niche where it shines (over-fetching reduction, polymorphic clients), more complex everywhere else. Default to REST unless you have a specific reason.
iPaaS: when to lean on it[/HEADING>
"Integration Platform as a Service" — Zapier, Make, n8n, Pipedream, Workato. They abstract the integration layer.
When iPaaS makes sense:
- Cross-platform integrations between mature SaaS products
- Customer / business-team-driven integrations (don't require dev work)
- Low to moderate volume
- Time-to-value matters more than long-term cost
When it doesn't:
- High volume (cost / latency become problems)
- Custom logic that exceeds the iPaaS's flow capability
- When the integration is mission-critical (debug story is harder)
n8n in particular has emerged as a viable self-hostable option in 2026 — open-source, Docker-deployable, 400+ integrations. We use it for internal automations where the alternative would be Zapier at $200/month.
Message queues: when you need decoupling[/HEADING>
For internal architecture (not external integrations), message queues are how systems decouple:
- RabbitMQ — mature, AMQP, complex routing
- Redis Streams / Kafka / Pulsar — high-throughput log-style
- NATS / NATS Jetstream — lightweight, modern, simpler than Kafka
- SQS / SNS / EventBridge — AWS-native equivalents
For "integrate WHMCS with XenForo" — too heavy. For "process incoming user events at scale" — appropriate.
The integration design checklist[/HEADING>
Before building any integration:
- What's the source-of-truth? One side must own each entity.
- What's the latency tolerance? Real-time, near-real-time, eventual?
- What's the failure mode? If the integration is down, what works / breaks?
- How do you debug a missing or duplicated event in production?
- How do you replay events after an outage?
- How do you migrate when the integration evolves?
Common patterns across web platforms[/HEADING>
- WHMCS → XenForo — webhook on order/upgrade, sync user role/group; the AIOR-style use case
- Stripe → backend — webhook on payment events, with signature verification
- Mailchimp → CRM — webhook on subscribe/unsubscribe; iPaaS often the easiest path
- E-commerce → ERP — heavier integration, often custom; consider message queue or middleware
- Form submissions → multiple destinations — server-side fan-out via webhook listeners or iPaaS
Avoiding vendor lock-in in integrations[/HEADING>
- Abstract vendor-specific clients behind your own interface
- Your business logic lives in your code, not in the iPaaS flow
- Document the integration so it can be rebuilt if the iPaaS goes away
- Avoid features unique to a single vendor unless they're load-bearing
One pattern we'd warn about[/HEADING>
Building integration logic into your application's main code path. The integration becomes part of the critical path; failures cascade. Decouple via webhooks + queues + retries.
One pattern that always pays off[/HEADING>
Logging every webhook in / out, with full payload and signature, retained for 30+ days. The day you need to debug "did Stripe send us this event" is the day you'll wish you had this log.
What's your integration stack? And — for the iPaaS folks — has the build-vs-buy line moved over the last year, in either direction?
For internal architecture (not external integrations), message queues are how systems decouple:
- RabbitMQ — mature, AMQP, complex routing
- Redis Streams / Kafka / Pulsar — high-throughput log-style
- NATS / NATS Jetstream — lightweight, modern, simpler than Kafka
- SQS / SNS / EventBridge — AWS-native equivalents
For "integrate WHMCS with XenForo" — too heavy. For "process incoming user events at scale" — appropriate.
The integration design checklist[/HEADING>
Before building any integration:
- What's the source-of-truth? One side must own each entity.
- What's the latency tolerance? Real-time, near-real-time, eventual?
- What's the failure mode? If the integration is down, what works / breaks?
- How do you debug a missing or duplicated event in production?
- How do you replay events after an outage?
- How do you migrate when the integration evolves?
Common patterns across web platforms[/HEADING>
- WHMCS → XenForo — webhook on order/upgrade, sync user role/group; the AIOR-style use case
- Stripe → backend — webhook on payment events, with signature verification
- Mailchimp → CRM — webhook on subscribe/unsubscribe; iPaaS often the easiest path
- E-commerce → ERP — heavier integration, often custom; consider message queue or middleware
- Form submissions → multiple destinations — server-side fan-out via webhook listeners or iPaaS
Avoiding vendor lock-in in integrations[/HEADING>
- Abstract vendor-specific clients behind your own interface
- Your business logic lives in your code, not in the iPaaS flow
- Document the integration so it can be rebuilt if the iPaaS goes away
- Avoid features unique to a single vendor unless they're load-bearing
One pattern we'd warn about[/HEADING>
Building integration logic into your application's main code path. The integration becomes part of the critical path; failures cascade. Decouple via webhooks + queues + retries.
One pattern that always pays off[/HEADING>
Logging every webhook in / out, with full payload and signature, retained for 30+ days. The day you need to debug "did Stripe send us this event" is the day you'll wish you had this log.
What's your integration stack? And — for the iPaaS folks — has the build-vs-buy line moved over the last year, in either direction?
- WHMCS → XenForo — webhook on order/upgrade, sync user role/group; the AIOR-style use case
- Stripe → backend — webhook on payment events, with signature verification
- Mailchimp → CRM — webhook on subscribe/unsubscribe; iPaaS often the easiest path
- E-commerce → ERP — heavier integration, often custom; consider message queue or middleware
- Form submissions → multiple destinations — server-side fan-out via webhook listeners or iPaaS
Avoiding vendor lock-in in integrations[/HEADING>
- Abstract vendor-specific clients behind your own interface
- Your business logic lives in your code, not in the iPaaS flow
- Document the integration so it can be rebuilt if the iPaaS goes away
- Avoid features unique to a single vendor unless they're load-bearing
One pattern we'd warn about[/HEADING>
Building integration logic into your application's main code path. The integration becomes part of the critical path; failures cascade. Decouple via webhooks + queues + retries.
One pattern that always pays off[/HEADING>
Logging every webhook in / out, with full payload and signature, retained for 30+ days. The day you need to debug "did Stripe send us this event" is the day you'll wish you had this log.
What's your integration stack? And — for the iPaaS folks — has the build-vs-buy line moved over the last year, in either direction?
Building integration logic into your application's main code path. The integration becomes part of the critical path; failures cascade. Decouple via webhooks + queues + retries.
