This article focuses on HTTP synchronisation, which is the generic synchronisation method offered by the Figgo web service. The principle behind this synchronisation is to allow you to send Figgo absences to a third-party tool if we do not offer a dedicated connector (see the list of available connectors).
Format of the sent message
The message will be sent as follows:
URI: you must provide the URL that will be called each time an absence is created or deleted
Body: the payload
You can configure the events that will be sent by the web service:
- all events (absences created and pending approval, approved absences, deleted absences)
- approved events only (approved absences, deleted absences)
The header contains the following fields:
- Authorization, which contains the authorisation key you provide.
Authorization: Basic YWxhZGRpbjpvcGVuc2VzYW1l
- X-Version: payload format version (provided by Figgo)
- X-Resource-Type: type of object sent (leave only in the current version)
- X-Event: the event that generated the call (created, approved, deleted)
Absences are sent by half-day, called leaves. So for a 2-day absence, the payload will contain 4 leaves.
"Annual leave 2020"
: "Annual leave"
Details of payload values
id: unique identifier for the leave
date: date of the leave
isAM: half-day (AM: true, PM: false)
leaveAccount: absence account
- id: the account’s identifier in Figgo
- name: the account’s name
- categoryId: the account category’s identifier, for yearly accounts
- categoryName: the account category’s name, for yearly accounts
value: duration in hours (only if the account is in hours)
- isConfirmed: the absence’s approved status
creationDate: date of creation
- isCancelled: cancelled status
cancellationDate: date of cancellation
Statuses of requests
This diagram shows the different possible request statuses based on actions taken in Figgo.
Events sent can be tracked in the synchronisation web service interface in Figgo.
For each event, you can see the details of the message sent and, if there is an error, re-sync the event manually or mark it as processed. In this case, it is no longer considered an error.
Synchronisation errors are reported on the dashboard of the administrator’s to-do list.
If the call fails, the event is sent to a queue for re-syncing. There are 4 successive queues at: 5 minutes, 15 minutes, 1 hour, 24 hours.