Webhooks vs MCP vs polling: choosing the right Slab5 integration pattern

Picking the wrong integration pattern is the difference between a 10-line handler and a three-day debugging session. Slab5 supports three: webhooks, MCP, and polling. Each one wins in a specific situation.

Webhooks: Slab5 tells you something happened

Use webhooks when an *external system* needs to react to a Slab5 event in near real time — a new lead lands, a ticket gets created, a CMS entry publishes.

Good fits:

• Pushing lead.created into Slack.
• Triggering a CDN cache purge on entry.published.
• Syncing invoice.paid into your accounting tool.

Not a great fit:

• Anything that requires a multi-step decision loop (use MCP).
• Anything you cannot afford to lose if your endpoint is briefly down (still use webhooks, but pair with the audit log for replay).

MCP: an agent does work inside Slab5

Use MCP when the work is *agent-driven*: read, decide, write. The agent calls tools, reads the result, calls more tools.

Good fits:

• Triage agents that read tickets and update priority.
• Drafting agents that propose CMS revisions.
• Cleanup agents that dedupe contacts.

Not a great fit:

• Deterministic ETL. Use REST.
• Anything that needs to fire the moment a Slab5 event happens. Use webhooks.

Polling: almost never

If you find yourself writing a loop that calls GET /v1/... every 30 seconds, stop. You almost always want a webhook instead.

The one place polling is reasonable: a batch reconciliation job that runs nightly and replays everything since the last successful checkpoint. Even then, audit log queries are usually a better tool.

A decision table

| Need | Use | |---|---| | React to a Slab5 event in another system | Webhook | | Have an LLM read and write workspace data | MCP | | Read business state from an internal dashboard | REST | | Write business state from your app code | REST | | Nightly reconciliation across systems | REST + audit log replay | | "Subscribe" to a stream of events | Webhook |

Hybrid patterns that work

The interesting integrations combine two:

• Webhook → MCP. New ticket.created webhook fires; your handler triggers an agent to triage it via MCP.
• MCP + REST. Agent uses MCP for the decision loop; your background job uses REST for bulk reads of the same workspace.
• Webhook + audit log. Webhook handler updates your downstream system; if it fails, a nightly reconciliation reads the audit log and replays.

The wrong pattern looks fine in development. It breaks the first time something fails, and the failure mode tells you which pattern you should have picked.

Use MCP for decision loops. Hand the agent a typed tool catalog scoped to its job. Pair with a webhook handler if the agent should trigger on an event.

Use REST for bulk reads and deterministic writes. Use webhooks for push notifications. Almost never poll.