Guide · Helpdesk
Syncing ticket status back to your own system: one webhook, one key, updates you can repeat
In short
Let the helpdesk own the ticket’s status and your system own everything else. Map the statuses once, keep a link both ways, take only the status-change events, and apply each one only if it’s newer than the last. When your side moves first, change the ticket through the API and expect a refusal now and then. Check the two against each other once a day.
Reviewed 10 November 2026. Terms used: Ticketing system.
Eight steps to a status that stays right
For the developer who wants “support is on it” to show on an order, a booking or an account page, and stay true.
Decide which system owns which field
Two systems that both write the same field will disagree sooner or later. Let the helpdesk own the ticket’s status and your system own the order’s. Your order page shows the ticket’s status; it doesn’t keep its own copy of it to edit.
Map the statuses once, in plain words
Helpdesk statuses are written for agents. Agree with support what each one means on your side, and what a customer or a colleague should read there.
A status map for an order page open, in progress → Support is working on it
waiting on customer → Waiting for your reply
waiting on a third party → Waiting on the courier
resolved → Sorted (can be reopened)
closed → Closed
reopened → Back with support
Keep a link both ways
Store the ticket’s id on the order, and the order number on the ticket in a field you can search. Then either side can find the other without matching on names or email addresses.
Take the status changes, not every update
Subscribe to the events that change what you show: status changed, resolved, closed and reopened. An edited subject or a new tag is noise for an order page. A status event that says what it moved from and to lets you check you’re in step.
Apply each change once, and only if it’s newer
Keep the event ids you’ve applied and skip a repeat. Keep the time of the last change you applied, too, and ignore an older one that arrives late, so a retry can’t move the status backwards.
The rule in your handler 1. Seen this event id? Stop.
2. Older than the last change applied? Stop.
3. Same status you already show? Note the id, stop.
4. Otherwise: map it, save it, note the id and the time.
When your side moves first, use the API
A refund that went through, a part that arrived: move the ticket through the API with a reason a person can read. The helpdesk may refuse a move its workflow doesn’t allow, or one someone else beat you to. Read the ticket again, then decide; don’t retry blindly.
Don’t send a change back to where it came from
When your system moves a ticket, the status event comes back to you a moment later. Because step 5 skips a status you already show, it ends there instead of starting a loop.
Check the two against each other once a day
Webhooks can stop for a while: your endpoint was down past the last retry, or someone changed a ticket by hand. List the tickets your integration made or touched, by last activity, compare each status with what you show, and fix the difference.
Copying every field vs syncing only the status
Who owns the data
- Copying every field
- Both systems, so they disagree
- Syncing only the status
- The helpdesk owns the ticket, you own the order
Events you handle
- Copying every field
- Every update
- Syncing only the status
- Status changes
What a late event can do
- Copying every field
- Overwrite a newer value
- Syncing only the status
- Nothing: older events are ignored
What drifts
- Copying every field
- Anything
- Syncing only the status
- Only the status, and the daily check finds it
How it works in Axonave
Status events with from and to, and moves the workflow allows.
In Axonave a ticket is open, in progress, waiting on customer, waiting on third party, resolved, closed or reopened. The ticket.status_changed webhook says what it moved from and to, with the reason when one was given, and every event’s body carries the ticket’s status, its last update time and its custom fields, so your order number comes back with it. Each delivery is signed and has an event id that stays the same in every retry. A key with tickets:write moves a ticket along the workflow’s own paths: a move the workflow doesn’t allow, such as a closed ticket going back to in progress instead of being reopened, is refused, and one that another change beat is refused with the status the ticket has now. The API lists tickets by status, by source (api marks the ones keys created) and by date, sorted by last activity, up to 100 at a time. The API covers tickets only.
- One key per integration, scoped and with an expiry
- Retries carry the same event id, so a repeat is easy to skip
- Every plan has it, with the helpdesk
Settings → API & webhooks in our demo workspace: a webhook to the order desk’s endpoint and its delivery log, each delivery answered with HTTP 200 and a redeliver button beside it.
Common questions
Does the status event say what the status was before?
Yes. ticket.status_changed carries the status it moved from and to, and the reason when one was given.
Can our system resolve or close a ticket?
Yes, with a key that has tickets:write, along the moves the workflow allows. A closed ticket can only be reopened.
What happens if two changes cross?
The second one is refused with the status the ticket has now, so your code can read the ticket again and decide.
How do we find the tickets our integration created?
List tickets with the source api. Tickets a key creates are marked that way.
Can we sync a lead’s or a deal’s status the same way?
No. The API and webhooks cover tickets only.
See it working with your own customers.
We reply within one business day by email or WhatsApp.