A job completed webhook is a message your field service software sends to another system when a technician marks a job complete. For most service businesses it's the most useful event there is, because completion is when follow-up, reporting, commission and warranty paperwork all start. Below are six things teams build on it, and the four rules your receiving system has to follow so those automations don't double-fire or break.
Why "completed" is the event that matters
Plenty happens to a job before it's done: it's created, scheduled, reassigned, put on hold. Most of that is internal. Completion is when the outside world should hear about it. The customer expects a follow-up. The CRM needs to know. The owner wants to see the day's output. Whoever runs payroll needs to know which jobs count for commission.
If all of that waits on someone in the office, it happens late or not at all.
6 automations teams build
1. Update the CRM
Move the customer's opportunity to completed, log the visit date and job type, and start whatever follow-up fits. Most teams build this one first. The setup, including how to match customers and avoid duplicate notes, is in how to connect field service software to your CRM.
2. Start the right follow-up email
Different jobs deserve different follow-ups. A new install might get a maintenance-plan offer a week later. A drain cleaning might get a reminder in six months. Use the job details in the event to pick the sequence in your email marketing tool.
3. Post high-stakes jobs to team chat
Not every completion needs an announcement. A no-heat call on a January night might, and so might a commercial fire alarm inspection with a contract deadline. Filter on job type or priority and post those to the channel the operations team watches.
4. Flag jobs for commission review
If technicians earn commission or spiffs on certain job types, the webhook can add each qualifying job to a review sheet the day it's done, instead of someone rebuilding the list from reports at the end of the pay period. FSM Navigator doesn't run payroll; this feeds whatever you use.
5. Stream completions into reporting
If you keep a data warehouse or a BI tool, send each completed job there as it happens. Morning reports stop depending on an overnight export that sometimes fails quietly.
6. Start install or warranty paperwork
For equipment installs, completion is when registration and warranty paperwork should start. The webhook can create the task in whatever system tracks it, so it doesn't sit in a technician's truck for two weeks. Multi-stage projects on work orders are broken into their own jobs, so you can act on the stage that counts as "installed".
The 4 rules every receiver should follow
These apply whether your receiver is a developer's service or an automation tool. They're common webhook practice; Stripe's webhook documentation, for example, makes the same points about its own webhooks.
Rule 1: Check the signature before you trust it
Anyone who knows your endpoint URL can send it data. A signed webhook lets your receiver confirm the message came from your field service software and wasn't changed on the way. Stripe puts it plainly: "Without verification, an attacker could send fake webhook events to your endpoint".
FSM Navigator signs and time-stamps every request with a secret shown to you once, so your receiver can confirm it came from FSM Navigator and reject old requests. That second check stops someone from replaying a request they captured. The webhook help docs show how to check it.
Rule 2: Answer fast, then do the work
Your endpoint should confirm receipt straight away and do the slow work, like updating the CRM or sending emails, afterwards, for example from a queue. Stripe's advice is to return a success code "before any complex logic that might cause a timeout."
FSM Navigator waits 10 seconds for an answer. A receiver that takes longer is treated as a failure and tried again later, which means more duplicates for you to handle.
Rule 3: Expect duplicates, and ignore them
Retries are a feature: if your endpoint is briefly down, you still get the event later. The side effect is that the same event can occasionally arrive twice. Stripe's docs say endpoints "might occasionally receive the same event more than once."
Every FSM Navigator event has a unique id that stays the same on every retry and on a manual resend from the delivery log. Store the ids you've handled and skip any you've seen. That's the difference between one follow-up email and two.
Rule 4: Don't depend on the order
Don't build logic that assumes events arrive in the order they happened. Stripe, for one, says it "doesn't guarantee the delivery of events in the order that they're generated." A retried status change could land after the completion.
The safe pattern: treat each event as "something changed on this job". FSM Navigator's job events carry the time they happened and a version number, so your receiver can ignore an older update that shows up late, or fetch the job's current state from the API before acting.
Handle the awkward cases
Completed jobs don't always stay completed.
- Deleted after completion. Decide whether your CRM note, email sequence or commission flag should be reversed, or flagged for a person to check. Flagging is usually safer.
- Restored. A restored job sends its own event. Make sure it doesn't trigger a second round of follow-up emails.
- Updated after completion. Office staff often fix details after the fact. If a correction matters to your automation, handle the job updated event too.
A receiver checklist for your developer
Hand this to whoever builds the receiver:
- Accept POST requests over HTTPS at a public address that isn't guessable.
- Verify the signature on every request, reject anything that fails, and reject timestamps more than five minutes old.
- Reply with a 2xx status straight away and queue the event for processing.
- Look up the event id. If you've seen it, stop. If not, record it.
- For anything order-sensitive, compare versions or fetch the job's current state from the API.
- Handle completed, deleted, restored and updated events on purpose, not by accident.
- Log what you did with each event, so you can answer "why did the customer get that email?"
- Alert a person when failures pile up, or when events stop arriving.
Once it's running, check the delivery log weekly for failures. It keeps 30 days of history.
How FSM Navigator sends it
FSM Navigator is one app from first booking to renewals: online booking, quotes customers sign on their phone, intelligent dispatch that gets the right tech to every job, invoicing on site and service agreements that bring the customer back. On the Enterprise plan it sends a signed webhook when a job is completed, in addition to the job status changed event. It also sends job created, updated, deleted and restored; invoice paid; customer created; and service request received.
- The Owner and Managers add endpoints in the dashboard and tick the events each one gets.
- Every delivery is logged, and failed deliveries are retried, up to eight attempts in all over about 15 hours, with gaps growing from one minute to eight hours.
- Each event carries a unique id for duplicate handling.
- Apps can subscribe and unsubscribe to job and customer events through the REST API with REST Hooks.
The webhooks developer docs have the payload, headers and sample signature code. No developer? You can use an automation tool's webhook trigger instead; see sending field service jobs to Zapier with webhooks. Webhooks and the REST API are both on Enterprise; plan details are on the pricing page.