Event webhooks are on the way: what to use instead, today

Outbound event webhooks — Norbelys pushing a payload to your endpoint the moment a message sends, a reply arrives, or a domain’s DMARC status changes — are marked “on the way” on the integrations page. They aren’t live yet. This post won’t pretend otherwise, and it won’t promise a ship date, because we don’t have one to give you.

What it will do is give you a genuinely useful way to build the same class of integration today, without waiting: cursor-pagination polling for most cases, and MCP tools when you want something closer to real time. Neither is a downgrade dressed up as a solution — both are patterns plenty of production integrations run on permanently, webhooks or not.

Why this post exists instead of a launch date

We’d rather tell you the honest state of things and hand you a pattern that works now than have you build against a promise. If you’re deciding whether to start an integration today, the answer is yes — just build it on polling or MCP instead of assuming a webhook endpoint will exist next sprint.

Pattern 1: cursor-pagination polling

The core idea is simple: instead of Norbelys pushing changes to you, you pull changes from Norbelys on a schedule, asking only for what’s new since last time. Every list endpoint in the API already supports the two pieces you need for this — cursor pagination and timestamp fields — so there’s no special “polling API,” just the same endpoints used slightly differently.

Building a polling loop

Pick your resource and interval
Decide what you're watching (messages, people, an inbound-message feed) and how often actually matters for your use case — every 60 seconds and every 5 minutes are both reasonable; don't poll faster than your integration needs.
Store the last cursor or timestamp you saw
Persist a cursor (or a dateModified/updatedDate high-water mark) somewhere durable — a database row, a KV entry — keyed to that specific poll job.
Request only what's new
Call the list endpoint with the stored cursor, or filter by dateModified greater than your last-seen timestamp, so each poll returns only the delta instead of the whole collection.
Process the batch, then advance the cursor
Only persist the new cursor after you've successfully processed the batch — if processing fails partway, you want the next poll to pick up from where you last succeeded, not skip records.
Handle the empty case cheaply
Most polls will return nothing new. Make sure an empty response is a fast, cheap round trip, since it'll be the common case by far.

A minimal polling call looks like the standard cursor-pagination pattern any SDK or raw API call already uses:

const { data, nextCursor } = await client.messages.list({
  direction: "inbound",
  cursor: lastSeenCursor,
  limit: 50,
});

for (const message of data) {
  await handleNewReply(message);
}

if (nextCursor) {
  await saveCursor(nextCursor);
}

Why this isn’t a lesser pattern

Polling with a persisted cursor is how a large share of production integrations work even at companies that do offer webhooks — because polling has properties webhooks don’t: your endpoint doesn’t need to be publicly reachable, there’s no retry/signature-verification machinery to build, and a missed poll self-heals on the next one instead of requiring a dead-letter queue. The honest trade is latency — you’re bounded by your poll interval, not instant — which is a real cost for some use cases and irrelevant for most.

Pattern 2: MCP tools for near-real-time checks

If your integration is inside an AI agent rather than a traditional backend service, the Norbelys MCP server at mcp.norbelys.com/mcp is often a better fit than either webhooks or a polling loop you maintain yourself. An agent with MCP tools can ask Norbelys “any new replies since I last checked?” as part of its own reasoning loop — driven by the agent’s own cadence rather than a cron job you have to write and monitor. It’s the same underlying pull model as polling, just orchestrated by the agent instead of by your code.

This is a good fit when:

The consumer of the update is already an agent (a support triage agent, an SDR copilot) rather than a deterministic backend process.
You want “check for new activity” to be one tool call among several the agent already makes, instead of a separate infrastructure component.
Near-real-time is good enough — the agent checks on its own loop, not instantly on the event.

It’s a weaker fit for a strict backend-to-backend sync where you need a guaranteed, code-owned polling cadence — that’s still squarely pattern 1.

What webhooks will add when they ship

Being direct about the gap: what polling and MCP don’t give you is push — the API calling you the instant something happens, with no polling interval bounding your latency. That’s the piece event webhooks are meant to close, and it’s genuinely useful for the sub-minute-latency use cases (a reply that should trigger an instant Slack ping, for instance). We’re not pretending polling replaces that need permanently. We’re telling you it covers the overwhelming majority of integrations well today, and that waiting to build until webhooks ship is usually the wrong call.

Migrating later

When event webhooks do ship, a polling-based integration doesn’t need a rewrite — it needs an optional upgrade. The resources and fields you’re already reading are the same either way; a webhook payload will carry the same shapes your polling calls already return, because both are generated from the same OpenAPI contract. Build on polling now with the expectation that adding a webhook subscription later is additive, not a migration.

Frequently asked questions

Are Norbelys event webhooks live yet?

No. They're listed as "on the way" on the integrations page. Every other developer surface — the REST API, SDKs, CLI, and MCP — is live today.

What should I build instead right now?

Cursor-pagination polling for backend-to-backend sync, or MCP tools if the consumer is an AI agent that can check for updates as part of its own reasoning loop.

Will a polling integration need to be rewritten once webhooks ship?

No — it's expected to be an additive upgrade. Polling and future webhook payloads read from the same underlying resources and fields, generated from the same OpenAPI contract.

How fast can a polling loop realistically be?

As fast as you're willing to poll — many integrations run a 30-60 second interval comfortably. The honest trade against webhooks is latency, not correctness: you're bounded by the interval, not by an outage or a dropped push.

For the full list of what’s live today, see the developer portal; for the SDK you’d build a polling loop on top of, see the Node or Python quickstarts, or the MCP tool catalog if you’re building on the agent side. Norbe, the AI operator, uses this same pull model internally today.