# Dyflexis API The Dyflexis API gives you programmatic access to the workforce data that powers (automated) staff planning, time tracking, payrolling, absence management, workload information and staff capacity in Dyflexis. Endpoints are organised by resource, **Employees**, **Contracts**, **Time clock**, **Payroll**, **Absence**, **Information streams**, and so on. The version of each endpoint (`v0`, `api2`, `v3`) lives in the URL; you can mix versions in the same integration. ## Base URL ``` https://app.dyflexis.com/{systemName} ``` Replace `{systemName}` with the tenant identifier of the customer you are integrating with, the customer provides this value to you when they connect your integration (see the [`systemName` server variable](#section/Servers) below for details on where to find it). Every server URL in this specification (and any new environment added in the future) starts with this base; new environments extend it with additional path segments rather than introducing a different host. This is enforced by the `rule/server-url-base` lint assertion in `redocly.yaml`. Each version has its own URL prefix under that base: | Version | Prefix | Status | | --- | --- | --- | | v3 | `/api//v3/...` | Latest production, preferred for new integrations | | api2 (v2) | `/api2/...` | Stable production, use when no v3 equivalent exists | | v0 | `/api/v0/...` | Legacy, one endpoint kept for existing Business Intelligence consumers | ## Authentication Almost every endpoint requires an API key, sent in the `Authorization` header with the `Token` prefix: ``` Authorization: Token YOUR_AUTH_TOKEN ``` `YOUR_AUTH_TOKEN` is the API key issued to you by Dyflexis. To call an endpoint directly from these docs: open the operation, click **Try it**, and open the **Security** tab of the request panel. **Name** is pre-filled with `Authorization` and **API key** with `Token YOUR_AUTH_TOKEN`; replace `YOUR_AUTH_TOKEN` with your API key, keeping the `Token ` prefix. The key is kept in your browser's session storage only and is cleared when the session ends. ### API scopes Each token is issued with one or more **scopes** that gate which parts of the API it can call. A scope is a named permission on the token (for example `business`, `clock`, `payroll`, `absence`, `external_employees`, `information_lines`); every operation declares the scope it requires, and the scope must be **enabled on your token** before that operation will accept the request. A token without the required scope is rejected with `403 Forbidden`, even when the token itself is otherwise valid. Scopes are issued per integration, you do not pick them yourself. Ask a Dyflexis administrator to enable the scopes you need when you request your token. The required scope is listed on each operation. ## Beta endpoints Endpoints marked with a **BETA** badge are in active development. Their URLs, request and response bodies, and authentication may change at any time. Do not depend on them in production. They are listed inline with the resource they belong to so you can preview upcoming behaviour. ## Timezones All date and time values in this API are expressed in the **timezone configured on the customer's Dyflexis tenant**, not UTC and not the partner's local timezone. A shift returned as starting at `09:00` starts at `09:00` in the customer's configured timezone, regardless of where your client is running, and a timestamp you send in is interpreted the same way. The tenant timezone is a per-customer setting; if you integrate with customers in different countries, treat the timezone as a per-tenant property and read or store it alongside the data you process. ## Errors The API returns standard HTTP status codes. Successful responses are in the `2xx` range; client errors in the `4xx` range; server errors in the `5xx` range. | Code | Meaning | | --- | --- | | `200 OK` | Request succeeded | | `201 Created` | Resource created | | `400 Bad Request` | Validation failed or the payload was malformed | | `401 Unauthorized` | Missing or invalid authentication | | `403 Forbidden` | Token does not include the required scope | | `404 Not Found` | Resource or path does not exist | | `429 Too Many Requests` | Rate limit exceeded, back off and retry | | `500 Internal Server Error` | Unexpected server error | | `503 Service Unavailable` | Upstream system temporarily unavailable | Error bodies are returned as `application/json` **only when the request sends an `Accept: application/json` header**; without it the API may return an HTML error page instead, so always send that header. A JSON error body has the fields `title`, `status`, `detail`, `message` (the same text as `detail`), and `code`. Validation failures (`400`) add a `violations` array with one entry per invalid field (`propertyPath`, `title`, `type`). ## Rate limiting Requests are rate-limited per token. When a token exceeds the limit, requests return `429 Too Many Requests`. Implement exponential backoff on `429` and `5xx` responses, and avoid tight polling loops. ## Pagination List endpoints paginate with a `page` query parameter (or a path segment, depending on the version). Where supported, responses include a `_links` block with `self`, `next`, `prev`, `first`, and `last` URLs you can follow without recomputing. REST API for the Dyflexis workforce management platform. License: Proprietary ## Servers Production ``` https://app.dyflexis.com/{systemName} ``` Variables: - `systemName`: **Required.** The tenant identifier (also called the *system name*) of the customer envoirement you are integrating with. The system name is set by Dyflexis when the customer's environment is created and is **provided to you by the customer** when they connect your integration, partners do not pick or generate this value themselves. The same value is what the customer sees as the first path segment of their own Dyflexis URL (`https://app.dyflexis.com//...`), so if you are unsure of the value for a particular customer, ask them or have them check their browser address bar. The same system name is used for every endpoint on every API version. The default `your-tenant` shown here is a placeholder and must be replaced with the customer's real system name before sending a request. Default: "your-tenant" ## Security ### apiKey **Required.** Authenticate with the API key issued to you by Dyflexis. The wire format is: ``` Authorization: Token YOUR_AUTH_TOKEN ``` In the Try-it console, the **Security** tab comes pre-filled: **Name** contains `Authorization` and **API key** contains `Token YOUR_AUTH_TOKEN`. Replace `YOUR_AUTH_TOKEN` with your API key, keeping the `Token ` prefix. API keys are scoped to permissions (`payroll`, `clock`, `business`, `absence`, `external_employees`, `employee_data`, `employee_mappings`, `attendance_registration`, `information_lines`, `payroll_hours`, `forecasting`, `setu`); the required scope is shown on each operation. Type: apiKey In: header Name: Authorization ### XDyflexisAuthToken Legacy authentication for the `v0` endpoints only: send the API key issued to you by Dyflexis in the `X-Dyflexis-AuthToken` header, without a prefix. Every other endpoint authenticates with the `Authorization: Token ...` header instead. Type: apiKey In: header Name: X-Dyflexis-AuthToken ## Download OpenAPI description [Dyflexis API](https://public-facing-dyflexis.redocly.app/_bundle/openapi.yaml) ## Offices & departments Offices are the top-level organisational units in Dyflexis; departments are nested inside them. Use these endpoints to discover the offices you can write data against and to fetch the full department tree of an office. ### Fetch the department tree - [GET /api/department-management/v3/tree](https://public-facing-dyflexis.redocly.app/openapi/offices-and-departments/getdepartmenttree.md): Requires scope: business or payroll. Retrieves all organizational units (offices, department groups, and departments) in a hierarchical tree structure. For a hospitality group, this typically returns each hotel or restaurant as an office, with departments such as Front of House, Kitchen, Housekeeping, and Bar nested underneath. ### List offices - [GET /api2/offices](https://public-facing-dyflexis.redocly.app/openapi/offices-and-departments/listoffices.md): Requires scope: external_employees or clock. > Legacy, Kept for existing integrations. New integrations should use GET /api/department-management/v3/tree, which returns offices together with their department structure in one call. Returns a list of all available offices. This will not include department groups or departments. ## Employees Employees are the people working in your organisation. Use these endpoints to list employees; to map a Dyflexis employee to an external personnel number; and to create or update an external employee record from your own HR or payroll system. Three list endpoints are exposed under different token scopes so each consumer sees only the data its scope is allowed to read: `business`, `clock`, and `payroll`. ### List employees - [GET /api/business/v3/employees](https://public-facing-dyflexis.redocly.app/openapi/employees/listbusinessemployees.md): Requires scope: business. Fetches all active employees, their labels, and their card numbers. ### List personnel numbers - [GET /api2/employee-mappings](https://public-facing-dyflexis.redocly.app/openapi/employees/listpersonnelnumbers.md): Requires scope: employee_mappings. > Legacy, Kept for existing integrations. New integrations should use GET /api/business/v3/employees, which returns the same mapping (employeeId and personnelNumber) along with the full employee record. Returns a list of personnel numbers and their corresponding Dyflexis employee ids. Employees that do not have a personnel number will be omitted. ### Create or update an employee - [POST /api2/external-employees/{employeeReference}](https://public-facing-dyflexis.redocly.app/openapi/employees/createorupdateemployee.md): Requires scope: external_employees. You can use this endpoint to send employee data to Dyflexis. This will create an external employee in Dyflexis, or update an existing external employee if one with the same unique reference already exists. An external employee will need to be connected to either an existing or a new Dyflexis employee within the Dyflexis application. An administrator can do this by using the widget in the employee overview page, or by using the external employee connection settings screen. Once connected, the Dyflexis employee will be kept in sync with the external employee whenever data is sent to this endpoint. ## Employment contracts Employment contracts describe an employee's terms of employment, office, contract type, hours, salary, and validity period. Use these endpoints to list available contract types and to push contracts from your HR system into Dyflexis. ### List contract types - [GET /api2/contract-types](https://public-facing-dyflexis.redocly.app/openapi/employment-contracts/listcontracttypes.md): Requires scope: external_employees. Returns a list of all available contract types ### Create or update contracts - [POST /api2/external-employees/{employeeReference}/contracts](https://public-facing-dyflexis.redocly.app/openapi/employment-contracts/createorupdatecontracts.md): Requires scope: external_employees. ## Information streams Information streams hold time-series workload and capacity data that drives forecasting and demand-based scheduling in Dyflexis, for example "covers per hour" in a restaurant, "transactions per hour" in a retail store, or "room occupancy per day" in a hotel. Use these endpoints to register a stream, push data points into it, and read back what has been stored. The **beta** `/information-streams/v3/...` family is in active development. It offers stream CRUD, bulk reads, and a configuration-driven data-point payload. ### Onboarding flow When integrating a new information stream, follow these four phases in order: 1. **Create the stream.** Register the stream with `POST /information-streams/v3/streams`, declaring its `type`, `unit`, `category`, `granularity`, and, optionally, the `departmentIds` it covers. The granularity is fixed at creation time and cannot be changed later, so pick the finest grain you can reliably supply (typically `hour` for hospitality, `day` for retail). 2. **Backfill historical data.** Push every available realised data point from the past into the stream using `POST /information-streams/v3/datapoint/{key}`. Forecast quality depends on history, so the more representative the backfill (ideally one or more full seasonal cycles), the sooner Dyflexis can produce useful forecasts on top of the stream. 3. **Push new data in (near) real time.** Once history is in, keep the stream current by sending new data points as soon as they are realised in the source system, ideally as each underlying period closes (end of hour, end of day, etc., depending on the configured granularity). 4. **Understand roll-ups.** Verify that the data you pushed at the configured granularity rolls up correctly into the higher granularities your customer reports on in Dyflexis (see below). ### Roll-ups Roll-ups happen **bottom up**: hour → day → week → month → quarter → year. Push data at the **lowest granularity you have available** and Dyflexis aggregates it into every coarser bucket automatically. The reverse is not true, sending only daily totals will not give you hourly detail later, so always push at the finest grain the source system can produce. > **A "work day" is not always a calendar day.** A work > day in Dyflexis is the **operating day** the customer > uses to run their business, which can differ from the > calendar day that runs `00:00`-`23:59`. Many hospitality > customers stay open past midnight; for example, a bar > that opens on Friday at `19:00` and closes Saturday at > `04:00` is operating a single Friday shift, not two > separate days. In that case organisations prefer the > workload (e.g. `revenue`) realised between Saturday > `00:00` and `04:00` to be rolled up to **Friday**, not > Saturday, so that daily, weekly, and monthly totals match > how the business actually reports on itself. The cut-over time between work days is configured per office on the customer's tenant. As an integrator you do not need to shift timestamps yourself, push each data point at the actual clock time it occurred and Dyflexis will roll it up to the correct work day. ### Fetch information stream data points - [GET /information-streams/v3/data-points](https://public-facing-dyflexis.redocly.app/openapi/information-streams/listinformationstreamdatapoints.md): Requires scope: forecasting. > Beta, This endpoint is in active development. URLs, request and response bodies, headers, and authentication may change at any time. Do not rely on it in production. Returns data points for a single information stream. The timestamps specify the lower bound of the time window, where the window is granularity long. For example, if granularity="hour", the value at "2026-04-02 11:00:00" indicates the value between "2026-04-02 11:00:00" and "2026-04-02 12:00:00". If granularity is not provided, the configured granularity of the information stream will be used. ### List information streams - [GET /information-streams/v3/list](https://public-facing-dyflexis.redocly.app/openapi/information-streams/listinformationstreams.md): Requires scope: forecasting. > Beta, This endpoint is in active development. URLs, request and response bodies, headers, and authentication may change at any time. Do not rely on it in production. Returns information streams available to the authenticated token (scoped by the location selection logic). Filtering is supported via query parameters. List parameters (departmentIds, categories, types, units) are provided as comma-separated values. If groupBy is provided, the response shape changes to a grouped payload. ### Create or update an information stream - [POST /information-streams/v3/streams](https://public-facing-dyflexis.redocly.app/openapi/information-streams/createorupdateinformationstream.md): Requires scope: forecasting. > Beta, This endpoint is in active development. URLs, request and response bodies, headers, and authentication may change at any time. Do not rely on it in production. Create or update the metadata for an information stream. Important notes: - When updating an existing information stream, include all keys to avoid unintentionally resetting values to their defaults. - departmentIds is optional. When provided, all department IDs must belong to the same office. - On create, departmentIds may be omitted; the stream is then created without linked departments. - On update, departmentIds is only applied when a non-empty list is provided. Omitting it (or sending an empty list) leaves the existing departments unchanged. - granularity is required when creating a new information stream. - When updating an existing information stream, granularity is optional. If provided, it must match the already configured granularity. Changing granularity through this endpoint is not supported. - When onboarding a newly realized workload information stream, ensure that all historically realized data is fully inserted. ### Store data in an information stream - [POST /information-streams/v3/datapoint/{key}](https://public-facing-dyflexis.redocly.app/openapi/information-streams/storeinformationstreamdata.md): Requires scope: forecasting. > Beta, This endpoint is in active development. URLs, request and response bodies, headers, and authentication may change at any time. Do not rely on it in production. Create or update one or more data points for the information stream’s base (configured) granularity channel. Access: Requires an API token that includes the forecasting scope. The forecasting module must be enabled for the customer. Only streams with source api or ai_forecast_engine can be written; other sources respond with 403 Forbidden. Stream shape: The stream must be migrated to the v3 structure (configured granularity and matching data channel). Legacy v2-only streams respond with 400 Bad Request (migration required). Granularity: If granularity is set on an item, it must exactly match the stream’s configured granularity. If omitted, that configured granularity is assumed. Minute is not yet supported and will result in an error. Unlike the deprecated timeseries upsert, this endpoint does not accept a coarser granularity than the stream to split across finer steps, declared granularity must match the stream. Value 0: A numeric 0 is stored on the base channel for that period (so it is distinct from a missing point). Coarser channels are recalculated from the base channel. All values, including 0, are applied with the same upsert behavior. Rollups: After successful writes, coarser granularity channels (e.g. day, week, …) are recalculated from the base channel where those channels exist. Successful requests always return 200 OK with an empty body. The endpoint does not distinguish between insert and update. ## Scheduling List scheduled shifts and the audit trail of schedule mutations (creations, modifications, deletions). The mutation feed is a legacy v0 endpoint kept for existing Business Intelligence consumers, there is no v3 equivalent yet. ### List scheduled shifts - [GET /api/business/v3/scheduled](https://public-facing-dyflexis.redocly.app/openapi/scheduling/listscheduledshifts.md): Requires scope: business. Returns a list of available shifts ### Schedule mutations - [GET /api/v0/mutation](https://public-facing-dyflexis.redocly.app/openapi/scheduling/listschedulemutations.md): Authentication: legacy X-Dyflexis-AuthToken header (see the Legacy v0 token security scheme), not Authorization. > Legacy, Kept for existing Business Intelligence consumers. Avoid for new integrations; there is no v3 equivalent yet. Returns a list of changes in the schedule for the specified period, limits to 500 a page. ## Clocked hours Record clock-in and clock-out events for an employee against a specific clocking device. Both endpoints require the `clock` token scope. ### Register a clock-in - [POST /api/clock/v3/clock-in](https://public-facing-dyflexis.redocly.app/openapi/clocked-hours/registerclockin.md): Requires scope: clock. Registers a clock in moment for an employee. ### Register a clock-out - [POST /api/clock/v3/clock-out](https://public-facing-dyflexis.redocly.app/openapi/clocked-hours/registerclockout.md): Requires scope: clock. Registers a clock out moment for an employee. ### List clock moments - [GET /api2/attendance-registration/{date}](https://public-facing-dyflexis.redocly.app/openapi/clocked-hours/listclockmoments.md): Requires scope: attendance_registration. ## Registered hours Registered hours are the **confirmed clocking time** for an employee, after rounding rules and break-time deductions have been applied. They are derived from clocked or manually entered time and represent the finalised, payable hours, distinct from the raw clock-in/clock-out events. Use these endpoints to fetch registered hours, and to retrieve attendance registrations (the merged record of planned shifts and clocked hours) for a given date. Useful for reporting, time-and-attendance dashboards, and reconciliation against scheduled hours. ### List registered hours - [GET /api/business/v3/registered-hours](https://public-facing-dyflexis.redocly.app/openapi/registered-hours/listregisteredhours.md): Requires scope: business. Returns a list of available registered hours ## Payroll The Payroll endpoints implement a **bi-directional flow** between an external payroll system and Dyflexis: - **Payroll → Dyflexis (employee sync).** The payroll system is typically the source of truth for the workforce. Employee and contract data can be synced from the payroll system into Dyflexis so that scheduling, time-tracking, and absence administration all operate on the same employee master that payroll uses. The endpoints for this direction live under [**Employees**](#tag/Employees) and [**Employment contracts**](#tag/Employment-contracts). - **Dyflexis → Payroll (confirmed hours).** Once a payroll period closes in Dyflexis, Dyflexis makes **all confirmed hour information** for that period, aggregated per day and per department, available for the payroll system to pick up and process. Each finalised period is published on a queue you poll and acknowledge, so no period is missed or processed twice. Concretely, this resource exposes hours aggregated per day and per department for a payroll period, the queue of finalised payroll periods waiting to be picked up by an external payroll system, and the wage components that periods produce. Typical export flow (Dyflexis → Payroll): 1. Poll `GET /api2/payroll/queue/from/{lastQueueId}` for new items. 2. For each item, fetch the period hours from `GET /api/payroll/v3/hours-per-day/...` or `GET /api/payroll/v3/hours-per-department/...`. 3. Acknowledge the item with `POST /api2/payroll/queue/{queueId}/status`. ### List payroll employees - [GET /api/payroll/v3/employees](https://public-facing-dyflexis.redocly.app/openapi/payroll/listpayrollemployees.md): Requires scope: payroll. Fetches all active employees and their contracts. Returns up to 100 employees per page. ### Fetch hours per day - [GET /api/payroll/v3/hours-per-day/{officeUrl}/{contractTypeGroupName}/{period}](https://public-facing-dyflexis.redocly.app/openapi/payroll/gethoursperday.md): Requires scope: payroll. Returns a list of all hours, allowances, and expenses in the requested locked payroll period. Only days that have either hours, allowances or expenses will be included. ### Fetch hours per department - [GET /api/payroll/v3/hours-per-department/{officeUrl}/{contractTypeGroupName}/{period}](https://public-facing-dyflexis.redocly.app/openapi/payroll/gethoursperdepartment.md): Requires scope: payroll. Returns a list of all hours, allowances, and expenses in the requested locked payroll period, grouped by department. For the neutral hour types, for example sickness, leave or all the allowances are grouped by the primary department of the employee. Only days that have hours, allowances, or expenses will be included. ### List wage components - [GET /api2/payroll/wage-components](https://public-facing-dyflexis.redocly.app/openapi/payroll/listwagecomponents.md): Requires scope: payroll_hours. Lists all available wage components with their user friendly display names. This list can be used as an aid in mapping the wage component fields to their corresponding fields in other systems. Wage components are defined by using the wage component dropdown for columns in the Chronos sheet. ### Fetch the payroll period queue - [GET /api2/payroll/queue/from/{lastQueueId}](https://public-facing-dyflexis.redocly.app/openapi/payroll/getpayrollperiodqueue.md): Requires scope: payroll_hours. Dyflexis allows the user to "send" a locked payroll period for external processing. These payroll periods are then added to a queue which you can fetch using this endpoint. Each entry in this list has a unique queue id and a URL you can use to fetch the payroll information. The endpoint will list all queue items that have been created after lastQueueId, limited to a maximum of 10 items, so you can easily see whether there are new queue items to process. Use 0 as lastQueueId to get the very first 10 queue items. You will need to keep track of which queue ids you have already processed in order to prevent processing remuneration information more than once. ### Update queue item status - [POST /api2/payroll/queue/{queueId}/status](https://public-facing-dyflexis.redocly.app/openapi/payroll/updatepayrollqueuestatus.md): Requires scope: payroll_hours. You can update the status of a queue item in Dyflexis when processing the payroll period queue. The status is displayed in the Dyflexis payroll page. ### Payroll period ready - [POST payrollPeriodReady](https://public-facing-dyflexis.redocly.app/openapi/payroll/payrollperiodreadyevent.md): > Webhook, Dyflexis sends this POST request to a URL you host. See the Webhooks guide for how to register your receiver and what it must return. Sends a message when the payroll data is ready. You can use the payload to call a desired endpoint. The webhook can't be registered with this API. Please register this webhook in Dyflexis. ## Absence Manage sick-leave registrations: list them, update their status (e.g. mark as recovered), and read the full status history of a single registration. ### Get sick leave status history - [GET /api/absence/v3/sick-leave/{sickLeaveRegistrationId}/status-history](https://public-facing-dyflexis.redocly.app/openapi/absence/getsickleavestatushistory.md): Requires scope: absence. Returns the full status transition history for a sick leave registration, ordered chronologically (earliest first). Each entry represents a status change that occurred during webhook processing or as reported by the external integration partner. ### List sick leave registrations - [GET /api/absence/v3/sick-leave](https://public-facing-dyflexis.redocly.app/openapi/absence/listsickleaveregistrations.md): Requires scope: absence. Returns a list of sick leave registrations. ### Report sick leave status - [POST /api/absence/v3/sick-leave/{sickLeaveRegistrationId}/status](https://public-facing-dyflexis.redocly.app/openapi/absence/reportsickleavestatus.md): Requires scope: absence. Report a status update for a sick leave registration. This endpoint is used by external integration partners to report the processing status of a sick leave registration that was sent via webhook. The status transitions follow a state machine: - in_progress, The registration is being processed by the external system. - success, The registration was successfully processed (terminal state). - failed, The registration failed to process. Can be retried by sending a new status. Note: The initial statuses new and acknowledged are set automatically by Dyflexis when the webhook is sent and received. Only in_progress, success, and failed can be reported via this endpoint. ### Sick leave registration event - [POST sickLeaveRegistration](https://public-facing-dyflexis.redocly.app/openapi/absence/sickleaveregistrationevent.md): > Webhook, Dyflexis sends this POST request to a URL you host. See the Webhooks guide for how to register your receiver and what it must return. Sends a message when a sick leave registration is created or recovered. Use the envelope field type to determine which event you received: - sick_leave_created, a new sick-leave registration has been filed. - sick_leave_recovered, an existing registration has been closed because the employee recovered. The webhook can't be registered with this API. Please register this webhook in Dyflexis. ## Employment agency SETU-standard endpoints for staffing companies (employment agencies) integrating with Dyflexis. Implements the Dutch SETU XML standard for Human Resource, Assignment, and Time Card messages. All endpoints accept and return `application/xml` and require the `setu` token scope. These endpoints are versioned and hosted under `/api/setu/{version}/...`. ### Submit a human resource - [POST /api/setu/1.4.1/humanResource](https://public-facing-dyflexis.redocly.app/openapi/employment-agency/submithumanresource.md): Requires scope: setu. The main element of the message, this container holds all elements needed to define a human resource (the person being staffed) in the SETU standard. SETU is the Dutch staffing industry's XML interchange standard. ### Submit an assignment - [POST /api/setu/1.4.1/assignment](https://public-facing-dyflexis.redocly.app/openapi/employment-agency/submitassignment.md): Requires scope: setu. The main element of the message, this container holds all elements needed to define an assignment (a human resource placed at a staffing customer) in the SETU standard. ### Time card event - [POST timeCard](https://public-facing-dyflexis.redocly.app/openapi/employment-agency/timecardevent.md): > Webhook, Dyflexis sends this POST request to a URL you host. See the Webhooks guide for how to register your receiver and what it must return. The main element of the message, this container holds all elements needed to define a time card (the reported hours, allowances and expenses of a human resource for a period). The webhook can't be registered with this API. Please register this webhook in Dyflexis.