Webhooks

Overview

Our Enterprise-package customers are able to use Webhooks with shyftplan.
💡Please contact us to set up webhooks for your shyftplan account.

Key concepts

With Webhooks, standardized messages are sent out to a receiving server of your choice whenever a configured event happens.

Using webhooks you can

  • create and maintain your own log history of events in shyftplan
  • enable delta-synchronization in your Middleware.

Delta-Synchronization?

When synchronizing, for example, absences between shyftplan and an external system, Webhooks can tell you that an absence in shyftplan has just been deleted. Then you only have to handle this one difference, the delta, between the two systems.
Without webhooks you can find out about deleted absences solely by GETting the complete list of currently existing absences and comparing this with a list of previously known absences that your Middleware needs to maintain somewhere.

Configurable events

Currently these events can be set to trigger a notification:

Action
Create
Update
Destroy (restorable for some objects, e.g. employments)
Restore
Really destroy (non-restorable)

These are the objects for which those events can trigger a notification:

ObjectAPI Endpoint
Absenceabsences
Shiftshifts
Employmentemployments
StaffShiftstaff_shifts
StaffShiftsTagstaff_shifts_tags

As an example, this is the notification your server will receive for a Destroy event on an Absence (if it is set):

The notifications are in JSON format. No guarantee can be given for the order of the entries, and new entries may appear.

📘

Additional mapping info included for integration customers (shyftconnect)

For shyftconnect users, the webhook messages (example above) will also include a foreign_id that is mapped to the primary id (field "id" above) of each object. The foreign_id is the key that you have sent to shyftplan during the creation of this object. The foreign_id usually reflects the ID that the mapped object has in your own storage system.

The addition will look like this (again, the order is not guaranteed, but the hierarchy level is set):

{
  "resource": "Absence",
  ... // same as above
  "object": {
    "id": 1501088,
    ... //same as above      
    "external_record_mappings": [
  	  {
        "foreign_id": "sc2_763534"
        "foreign_type": "shyftconnect" // "shyftconnect" is constant
	    }
  	]
  }
} 

Direction of transfer

shyftplan to external system

Relevant endpoints for this use case

n/a