Any partner using webhook data for reporting purposes should also do a daily scrape of ticket or clock_entry data to make sure nothing was missed
The information below is for internal purposes - When talking about this process externally, just say that we poll for the data
The topic of "Webhooks" is broken into 4 parts:
The Poller - A worker that retrieves data from the location
The Sender - A worker that makes API calls to the partner's server to send them the ticket/clock_entry data
The Webhook itself - The POST Request body that is sent to the partner
The Poller
retrieves data from the agent just like a regular GET call through the API
checks for new tickets/clock_entries roughly once a minute
retrieves open and closed tickets separately, but clock_entries together
retrieves 25 tickets/clock_entries per call and will page back until the comparator says that its seeing old data
e.g. A location that has been offline for a day will get webhooks for all of the POS activity that occurred while it was offline
However, it will only go out as a snapshot of the current state, so the partner won't get the full lifecycle of the ticket/clock_entry, like they would have if the location was online the entire time
passes the ticket data over to the comparator
relies on tickets and clock entries being returned with the
most recently opened first for open tickets/clock_entries
most recently closed first for closed tickets/clock_entries
The Sender
makes an API POST call to the partner's server with the webhook as the Request body
The Webhook
data should match the GET tickets/clock_entries API call results exactly, if taken at the same time for the ticket/clock_entry
All of the fields in the GET response should match the corresponding data in the webhook exactly
The webhook contains other metadata that is not included in the GET response
Troubleshooting Hints
If a location goes offline, the Poller will search for tickets/clock_entries it missed when it comes back online, but only to a maximum of 24 hours or 250 tickets, whichever comes first
Always ask for an example ticket/clock_entry ID if the customer reports that webhooks are "missing"
Always GET the ticket/clock_entry through the API and compare it to the last Changed webhook shown in Webhook Activity
If they are not identical, report it as a defect
Webhooks are a snapshot in time, so some activity may appear to be missed simply because of timing
e.g. If a closed ticket is reopened and then immediately closed again without something substantial changing, the comparator has no way of knowing to send out a new webhook
The Webhook Activity page has a secret search feature (data_id:) that you can add with the ticket/clock_entry ID to get display all related Webhooks