Blog / Platforms & migrations

Webhooks or polling: keeping your AI's context fresh

An AI assistant that reads yesterday’s data gives yesterday’s answers, with full confidence. How to choose between webhooks, polling or both, and how to keep the data your AI reads as fresh as the decisions it supports.

An AI assistant can only be as current as the data it reads. If a deal closed an hour ago and the assistant still sees it as open, it will recommend a follow-up that should never be sent, and it will do so fluently. Stale context does not look stale. It looks like a confident answer.

If you lead the team: what to ask

  • How fresh does the data the AI reads need to be, and is that written down for each source?
  • If an update from another system gets lost, what finds it and fixes it?
  • Can users see when the data behind an answer was last updated?

Keeping context fresh comes down to how you move changes from the systems where work happens into the place your AI reads from. There are two basic mechanisms, and most production systems end up using both.

Start with the freshness requirement

Before choosing a mechanism, decide how fresh each kind of data needs to be. The answer differs by source and by use:

  • A support assistant answering about an order status may need changes within seconds.
  • A daily summary of pipeline activity is fine with data a few hours old.
  • Reference data such as product catalogues or price lists may change only weekly.

Write the requirement down per source: “changes must be visible within N minutes”. It turns a vague wish for “real time” into a target you can design for and monitor.

Webhooks: the source tells you

With a webhook, the source system calls your endpoint when something changes. Changes arrive quickly and you are not spending requests asking about records that have not moved. In exchange, you take on several responsibilities:

  • Verify the signature. Your endpoint is public. Check the signature the provider sends on each request, so only genuine events are accepted.
  • Respond fast, process later. Acknowledge the event quickly and put it on a queue. Slow responses lead providers to time out and resend.
  • Expect retries and duplicates. Providers resend when they are not sure you received an event. Processing must be idempotent: handling the same event twice must leave the same result as handling it once, usually by recording each event ID.
  • Expect disorder. Events can arrive out of order. Compare timestamps or versions before overwriting newer data with older data.
  • Expect missed events. Your endpoint will be down at some point, a deployment will drop a request, or the provider will give up after its retries. Webhooks alone do not guarantee you have everything.

Polling: you ask the source

With polling, your system asks the source on a schedule: “what changed since my last check?” It is simpler to build and to reason about, it works with systems that offer no webhooks, and nothing is lost when your side is briefly down, because the next run picks up where the last one left off.

The trade-offs are delay and load. Data is only as fresh as the polling interval, and frequent polling runs into the provider’s rate limits. Polling works best when the source can filter by “modified since”, and when you store a reliable cursor or timestamp for each run. Without that filter, you end up re-reading everything.

The hybrid: events for speed, reconciliation for completeness

The robust pattern combines the two. Webhooks deliver changes quickly. A scheduled reconciliation job compares your copy with the source at a slower pace, for example nightly, and repairs whatever the events missed: dropped deliveries, records changed during an outage, deletions the provider never announced. Each mechanism covers the other’s weakness.

Two more habits make it dependable. Record, for each record, when it was last synchronised. And monitor the gap: if a source has sent no events for longer than usual, alert someone instead of assuming nothing happened.

What stale context does to AI answers

A report with old data is visibly dated. An AI answer built on old data reads as current. It recommends actions already taken, reports problems already solved and misses what just happened. Users who catch it once start checking every answer by hand, and the assistant loses the trust it was built to earn.

Two practical defences help beyond fresher pipelines: pass the “last updated” time into the model’s context, and show it to users next to the answer. Then a person can see how current the information is, and the model can be instructed to say when its data may be out of date. If you want to know where your own data stands, our AI readiness check looks at exactly this.

Freshness checklist

  • Is there a written freshness target for each source?
  • Are webhook signatures verified on every request?
  • Are events queued and processed idempotently, keyed by event ID?
  • Does polling use a “modified since” cursor and respect rate limits?
  • Does a reconciliation job repair missed changes on a schedule?
  • Is silence from a source monitored and alerted?
  • Does the AI, and the user, see when the data was last updated?

Written from our engineers’ work on production systems. Want a second opinion on your project? Talk to an engineer.

See the work →

Want us to look
at your site?

Tell us where traffic, revenue or your numbers stopped making sense. We will tell you what we would check first.

Prefer to write directly? enable JavaScript to see the address

Talk to an engineer

No sales theater. Tell us where your operation feels slow, repetitive, or difficult — an engineer reads every message.

Your message goes straight to our engineers at our address.