Webhooks for Job Changes: How to Push a Buying Signal API Event Into Your CRM in Real Time

There are two ways to find out that a contact changed jobs. You can ask, on a schedule, and hope the timing works out. Or you can be told, the moment it happens. The first is polling. The second is a webhook, and for a signal as time-sensitive as a job change, it is the difference between reaching a champion in their first week and reaching them after the seat is filled.

If you are wiring buying signals into your stack, the job change is the one worth building around, because the relationship already exists. This is how to receive it as a real-time event instead of a report you check on Monday.

Poll versus push, and why it matters here

A polling model asks a question on a timer: has anything changed since I last checked? It is simple to build, but it trades freshness for effort. Poll hourly and you hammer an endpoint for a signal that fires a few times a day. Poll daily and you accept up to 24 hours of lag on an event where the first few days matter most.

A webhook inverts the flow. Instead of you asking, the provider calls you the instant a move is detected. Your endpoint receives a payload, your automation runs, and the warm lead is in the CRM before a rep has opened their laptop. For a buying signal API, push is the right default: the events are sparse, individually valuable, and worth acting on the same day they land.

The reason the job change earns that urgency is the outcome gap behind it:

• Champion-sourced deals close with a 2.7x higher probability, in roughly half the sales cycle.
• You have a 60 to 70% chance of selling to an existing relationship, versus 5 to 20% for a cold prospect.
• Only about 6% of customers tell a vendor they moved. The other 94% just leave, so if you are not detecting the move automatically, that pipeline is invisible.

What a job change webhook payload should contain

A useful event is more than “someone moved.” To route and act on it without a human enriching the record first, the payload needs enough to answer who, where, and what to do next:

• Who moved, matched to your existing CRM record, not just a name and email that you have to reconcile.
• From where and to where: the old company and title, and the new company and title.
• When: the detected date, plus an intent-to-move signal in the cases where the move is not yet public.
• Who owned the relationship: the rep or CS owner tied to the original record, so the alert routes itself.

A minimal shape looks like this:

{
  "event": "contact.job_change",
  "contact": { "id": "crm_00421", "name": "Sarah J." },
  "from": { "company": "Acme", "title": "VP Revenue" },
  "to":   { "company": "NewCo", "title": "CRO" },
  "detected_at": "2026-08-19",
  "owner": "rep_14",
  "status": "hot_lead"
}

The exact field names vary by provider. What does not vary is the requirement: if your automation has to make a second call to figure out who this person is or who should get the alert, the event is doing half its job.

Wiring the endpoint to Salesforce or HubSpot

The pattern is the same regardless of CRM. Here is the loop most teams run:

1. Sync your contacts to the watch list. Push closed-won contacts, power users, and promoters into the provider. These are your champions, not every name in the table.
2. Stand up a receiver. Expose an HTTPS endpoint that accepts the webhook. Keep it thin: validate, acknowledge fast, and hand the work to a queue so a slow CRM write never causes a delivery to time out.
3. Write back on each event. Update the contact with the new company and title, create a task or a fresh lead, and stamp the source as “champion move” so it reports as its own channel.
4. Route both sides of the move. Assign the new-company lead to the rep who owned the relationship, and flag the account the contact left for customer success the same day. Every arrival is also a departure, and the account they left just lost its internal sponsor.

Three implementation details separate a webhook that works in the demo from one that survives production:

• Verify the signature. Treat the endpoint as public. Check the provider’s signature on every request so nothing else can post fake moves into your pipeline.
• Make writes idempotent. Delivery guarantees are usually at-least-once, so the same event can arrive twice. Key your CRM write on the event ID and no-op on repeats.
• Acknowledge, then process. Return 200 quickly and do the enrichment and CRM write asynchronously. Providers retry on non-2xx responses, and a synchronous CRM call is the most common cause of a timeout that triggers a duplicate.

Build versus buy

You can assemble this from a raw people-data source and your own receiver, and some teams do. The webhook plumbing is rarely the hard part. The hard parts are:

• Match rate. Correctly re-identifying a contact who changed their email, company, and sometimes their name is where most home-built pipelines leak.
• Freshness and intent. Detecting the move fast, ideally catching intent-to-move signals before the change is public, so the event fires while the window is open.
• Coverage beyond Salesforce. Many tools are Salesforce-first. If your team runs on HubSpot, Pipedrive, or Zoho, breadth matters more than one deep integration.

If you would rather not own the matching, enrichment, and CRM write-back, Champions runs the whole loop for you across Salesforce, HubSpot, Pipedrive, Zoho and others, with no app to install and no logins for reps. Champify, UserGems, and the rest of the job change tracking landscape each publish their own coverage and match-rate claims; compare them on those three axes rather than on whether they can send a webhook, because most can.

What the feed is worth

Take a CRM with 10,000 contacts. When you first turn detection on, roughly 20% surface as hot leads immediately, about 2,000 conversations available on day one. After that, expect 200 to 300 new warm leads every month as people keep moving, since 2 to 3% of B2B contacts change jobs monthly. Those are the events your webhook will carry.

Because the leads convert, Champions backs the signal with a contractual ROI guarantee: if champion-sourced revenue does not reach 2x your annual service fee, you are covered under our terms. Among the compared tools, only Champions offers that. What you build in-house, you insure yourself.

Where to start

The fastest way to see what the event stream is worth is to run detection against your own CRM first. Book a demo and we will show you the moves hiding in your database live, then walk through how the webhook and payload fit your stack. Prefer email? Reach us at [email protected] and we will get you the details.

Polling tells you a contact moved eventually. A webhook tells you the moment it happens, while the relationship is still warm and the seat is still yours to win.