Webhooks vs polling for city systems

Every integration has to answer one question: how does it find out that something changed? There are two basic answers. Either the source system tells you (a webhook), or you ask it on a schedule (polling). Databases add a third family of options.

Neither is always better. City systems vary widely in what they support, so most agencies end up using both.

It also helps to be clear about what "real time" needs to mean. A resident's complaint reaching a code officer within a minute is useful. A weekly summary arriving a minute after 7 am is not more useful than one at 7:15. Match the trigger to the work.

Webhooks: the system calls in

With a webhook, the source system sends a message to an address you give it whenever something happens, such as "request created" or "meeting published".

Good for:

• Things that should happen right away, like a resident's complaint becoming a case.
• Systems with many records but few changes, where asking repeatedly would waste calls.

Watch out for:

• Not every system has them. Accela's Construct API, for example, has no webhooks for record changes.
• Missed messages. If your receiver is down, some senders retry and some don't.
• Fake messages. Anyone who learns the address can send to it, unless you verify the sender.

Verify every webhook

A well-designed sender signs each message with a shared secret, usually an HMAC signature in a header. The receiver recalculates the signature and rejects anything that doesn't match. Some senders use a simpler shared token instead. Either is far better than accepting anything that arrives.

Polling: ask on a schedule

With polling, the integration asks the source on a schedule: "what changed since last time?"

Good for:

• Systems without webhooks.
• Batch work, like nightly exports or a morning digest.
• Situations where a short delay is fine.

Watch out for:

• Delay. A 15-minute schedule means up to 15 minutes before a change moves.
• Wasted calls. Polling too often can hit the vendor's rate limits.
• Gaps. If you track "since" carelessly, records can be missed or repeated.

Use a changed-since watermark

The right way to poll is to remember when the last good run happened and ask only for records changed since then. Many APIs accept a parameter for this, such as updateDateFrom in Accela or updated_since elsewhere. If a run fails, the watermark doesn't move, so the next run catches up.

Databases: three ways to notice a change

Many city systems are really databases: a permit system on SQL Server, a work-order table in PostgreSQL. You can watch them directly.

• A changed-column watermark. Poll for rows where an updated_at column is later than the last good run. Simple and works almost everywhere, as long as the column is kept up to date.
• SQL Server Change Tracking. SQL Server can record which rows changed, so you ask for changes without relying on a timestamp column.
• PostgreSQL LISTEN/NOTIFY. PostgreSQL can announce changes as they happen, close to a webhook for your own database.

How to choose

A few rules of thumb:

• Use webhooks for "something just happened" flows, and verify every message.
• Use schedules for batches and summaries, and for systems without webhooks.
• Run a slow scheduled sweep alongside a webhook flow if missing a message would matter.
• Set schedules in your own time zone, so "weekdays at 6 am" means your 6 am.

In SentraBridge

Every flow starts one of four ways: by hand, on a schedule in your time zone, when a system calls in, or when database rows change. Webhook triggers verify signatures for every Sentra product, plus generic HMAC or token checks for other senders.

"Only records changed since the last good run" is a setting on Get records. Database change triggers support changed-column polling, SQL Server Change Tracking and PostgreSQL LISTEN/NOTIFY. See triggers for the details.