Key takeaways

• The Events Log is Viventium's change-detection surface. No general outbound webhook is publicly documented anywhere in its API reference.
• The only public "web hook" endpoints are inbound and GetHired-specific, letting a partner notify Viventium rather than the reverse.
• The endpoint paginates by startAfterId, a cursor, not a page number, so you pass the last ID you saw and repeat until a short batch comes back.
• Events Log is scoped to one company and one division per call, so a multi-entity integration polls per division rather than once per client.
• Correct polling needs an overlapping window, a cursor walked to exhaustion, and a watermark that only advances once the window completes.

Viventium change detection

Building a Viventium integration puts this decision in front of you early: trust a webhook to tell you when something changed, or poll for it yourself.

For Viventium the answer is not close. The Events Log is the change-detection surface, and no general outbound webhook is publicly documented for the platform at all.

That matters because a missed change does not announce itself. An employee's coverage tier changes and the deduction never updates. A termination goes through in Viventium while the downstream benefits system still shows the person active. Nobody notices until an audit, a payroll run, or an angry email surfaces it.

The tradeoff is worth naming up front. If Viventium had a general outbound webhook it would beat polling on latency, no argument. What polling wins instead is completeness, and for change detection completeness is the property you cannot trade away.

This guide covers whether a Viventium webhook exists, what the Events Log endpoint actually accepts, how to poll it so nothing slips through, how to handle the duplicates that approach produces, and how to decide whether to build it yourself.

Does Viventium have webhooks?

Search for "Viventium webhook" and you will find something that is not what you expected. Viventium's API reference documents notification hooks under v1/gethired/notify/…, which let GetHired notify Viventium that an applicant reached a step or a new employee was onboarded.

That is inbound, and it is specific to one partner ATS. It is not a way for Viventium to notify your integration when a record changes.

A general outbound webhook subscription system, the kind that pushes a create, update, or delete event to your endpoint as it happens, does not appear anywhere in the public API reference. That does not rule out something available under a private partner agreement. Nothing in the open documentation describes a change feed you can subscribe to.

Which leaves the real question. Not webhook or polling, but whether you can poll well enough to catch everything a webhook would have told you.

Events Log and webhooks, compared

Laid side by side, the two mechanisms are not competing for the same job. One is a log you query. The other, where it exists at all, is a notification you receive.

That last row is the whole argument. A webhook, even a reliable one, tells you a change happened. It does not guarantee you have seen every change, because a dropped delivery or an unsubscribed event type fails silently. The Events Log has no such gap. You control the query, and you can prove you walked every record in the window you asked for.

What the Events Log endpoint actually accepts

The endpoint is scoped to a company and a division:

GET v1/export/companies/{companyCode}/divisions/{divisionCode}/events-log

It takes six parameters that matter for change detection:

Two of those shape the whole design.

startAfterId means the endpoint is cursor-paginated, not page-numbered. You do not request page 2. You take the last ID in the batch you just received, pass it as startAfterId, and request again. A loop written against page numbers will either miss records or re-read them when the underlying set shifts mid-walk.

The scope is one company and one division. There is no client-level Events Log call. A platform serving a client with twelve divisions polls twelve times per cycle, not once, and your rate budget and scheduler have to be built for that from the start. This is the single most underestimated cost of Viventium change detection.

How to poll the Events Log without missing a change

The pattern is straightforward once you accept that polling has to do the job a webhook cannot.

1. Set your poll interval. Pick it from how fresh downstream data needs to be. Five minutes for something that reacts immediately, hourly for something that tolerates a lag. Multiply by your division count before you commit to a number.
2. Query with an overlapping window. Set modifiedOnStartDate to your last successful poll minus a small buffer, a few minutes is usually enough. A modified-date filter is the same "what changed since" model HTTP defines for conditional requests in RFC 9110, and the overlap buffer covers a change landing right at the window edge.
3. Walk the cursor to exhaustion. Request with a limit, take the last ID from the response, pass it as startAfterId, and repeat until a batch comes back smaller than your limit. Only then treat the window as fully read.
4. Record the action and the record ID for every change before you do anything else with it.
5. Advance your watermark only after the full window succeeds. If the cursor walk breaks off partway, leave your last-poll timestamp where it was and re-run the same window next cycle.
6. Treat every poll as safe to retry. A GET is defined not to change state on the server, per RFC 9110, so retrying an interrupted poll costs nothing on Viventium's side. The duplicates that retry produces are yours to handle on the way in.

That last line is a promise with a catch. Retries and overlap windows both guarantee you will see some changes more than once.

Handling duplicates, stale data, and reconciliation

• Deduplicate by a stable event ID, not a timestamp. The CloudEvents specification, the vendor-neutral standard for describing an event, models exactly this: an id field a receiver uses to recognise it has already handled an occurrence. Track IDs for as long as your overlap window reaches back, and skip anything already seen.
• Fetch the current record before writing downstream. A duplicate delivered inside the overlap window can carry an earlier state if you write it naively. Pulling the live record at write time turns a duplicate into a no-op instead of a regression.
• Treat any Viventium webhook that does surface as a trigger and nothing more. Let it shorten the time until your next poll. Never let it replace the poll.
• Reconcile on a fixed schedule regardless of how well the poll loop runs. A nightly full pull, comparing complete record sets rather than deltas, catches the failure mode nothing above accounts for: a section or action value you never knew to filter on.

Put together that is a real system: a scheduled poller running per division, a dedup store, a reconciliation job, and monitoring across all three. None of it is exotic. All of it is work somebody has to build, run, and keep correct as Viventium's API changes underneath it.

Build it yourself, or offload it

Everything above is buildable in an afternoon and maintainable for years. Or it is the fourth integration your team has quietly built the same way, once per vendor.

That repetition is the honest argument for a managed layer, and it is worth being precise about which part it solves.

Bindbee connects to 67+ HRIS, payroll, ATS, and benefits systems, Viventium among them, so the poller, the dedup store, the reconciliation job, and the per-division scheduling do not get rebuilt per connector. Bindbee normalises what comes back into 40+ unified data models across HRIS, payroll, ATS, and LMS, so a coverage-tier change has the same shape whether it came from Viventium or the next payroll system you add.

What it does not do is beat a tight poll loop on latency. Bindbee's connectors sync every 24 hours by default, configurable, and webhooks fire when a sync starts, finishes, or fails and when synced records change. Your systems get a push instead of running the loop, and the underlying refresh is still the sync interval. If your product genuinely needs five-minute freshness on a Viventium change, the poll loop above is the mechanism that delivers it, and you should build it or configure the sync interval accordingly.

The trade is maintenance, not milliseconds. You stop owning per-vendor change detection. You accept a refresh cadence you set rather than one you control minute to minute.

Because this data covers payroll and benefits, handling matters as much as mechanism. Bindbee is SOC 2 Type II, ISO 27001, HIPAA, and GDPR compliant, and a standard BAA template is available.

You can see the Viventium connector directly, and the sync and webhook behaviour is documented in full at docs.bindbee.dev.

Healthee replaced 15 custom integrations with Bindbee. Newfront cut client onboarding from 8 to 12 weeks down to 48 hours.

We build the integrations. You build the product.

FAQ

Does Viventium have webhooks?

Not as an outbound change feed. The public API reference documents inbound notification hooks under v1/gethired/notify/…, which let the GetHired partner system notify Viventium. No general outbound webhook subscription is publicly documented.

How do I detect changes in Viventium?

Poll the Events Log at GET v1/export/companies/{companyCode}/divisions/{divisionCode}/events-log, filtering with modifiedOnStartDate and modifiedOnEndDate, and walking the startAfterId cursor until a batch returns fewer records than your limit.

How does the Events Log paginate?

By cursor. Pass startAfterId set to the last ID you received, along with limit, and repeat. It is not page-numbered, so a page-based loop will drop or repeat records when the underlying set shifts mid-walk.

Can I poll the Events Log for a whole client at once?

No. The endpoint is scoped to one company and one division per call, so a client with multiple divisions needs one poll per division per cycle. Size your schedule and rate budget accordingly.

Do I still need reconciliation if the poll loop is working?

Yes. A nightly full comparison catches the one failure the poll loop cannot see: a section or action value your filter never included.