Receiving webhooks from MetronHR

MetronHR reports15 events from time tracking, absences, personnel and shift planning to an address of your choice, signed to Standard Webhooks. A target subscribes to individual events, not to everything. Included in the Professional plan, at no extra charge and with no minimum number of licences.

As of:15. September 2026

The event catalogue

The names follow the pattern resource, dot, operation, in the same spelling as the REST addresses. Anyone reading time-entries.created knows without a table that the payload has the same shape as the response to a call for that same time entry.

  • Time entries

    Events
    created, updated, deleted
    What a receiver needs them for
    Payroll and project controlling. They report from every way of recording, including the terminal and the app.

  • Absences

    Events
    requested, approved, rejected, cancelled, updated
    What a receiver needs them for
    updated is the case a payroll system otherwise misses: the dates of an already approved holiday shift.

  • People

    Events
    created, deactivated, updated
    What a receiver needs them for
    Directory reconciliation. updated carries department, role, position, staff number and the start and leaving dates.

  • Shifts

    Events
    published, assigned, unassigned
    What a receiver needs them for
    Time management and access control. A change of staffing reports only after publication; before that the plan is a draft.

As of 15. September 2026. 15 events. What is binding is the app's OpenAPI document, not this overview.

The body of a delivery

{
  "id": "msg_01J...",
  "type": "absences.approved",
  "occurredAt": "2026-09-15T08:12:04.000Z",
  "tenantId": "01J...",
  "data": { "...": "wie GET /api/v1/absences/{id}" }
}

What makes a delivery secure

  • A signature per delivery to the Standard Webhooks scheme: HMAC-SHA256 over id, timestamp and body, in the headers webhook-id, webhook-timestamp and webhook-signature.
  • The secret can be rotated. The old one keeps signing for 24 hours so the receiver has time to switch.
  • A target is checked against internal networks when it is created. The server does not accept an address inside its own network.
  • webhook-id stays the same across every retry and is therefore the receiver's idempotency key.
  • Every target subscribes to individual events, and an event is delivered only if the business has released the resource for it.

When the receiver is down for a while

An outage on the other side costs no message, as long as it does not become permanent. The numbers are fixed and not configurable, so that a waiting target does not turn into a silent backlog.

  • The answer takes too long

    What the server does
    After 10 seconds the attempt counts as failed. Anyone needing longer is processing synchronously; the delivery belongs in a queue on the other side.

  • The target answers with an error

    What the server does
    Up to 6 attempts at growing intervals: after 2, 4, 8, 16, 32 and 60 minutes. The id stays the same throughout.

  • The target stays silent for good

    What the server does
    After 20 failures it is switched off, and the business is notified about that. A target that has been switched off collects nothing afterwards.

  • The target was deleted

    What the server does
    Waiting deliveries expire, with no further attempt.

As of 15. September 2026. Targets, subscriptions and the test button are in the company settings, under Integrations.

Webhooks are the way out. The way in is the REST API, and anyone who would rather have an assistant ask instead of a system takes the MCP server.

Questions about the webhooks

What we are asked most often about it.

Nothing extra. Outgoing webhooks belong to the Professional plan, like the REST API and the MCP server, at no extra charge and with no minimum number of licences. They are not included in the Team plan.

A POST with JSON. The body carries an id, a type, the time of the operation, the tenant and, under data, the same shape as the REST API response for the same resource. A receiver that uses both has one type and not two.

The delivery is retried up to six times at growing intervals: after 2, 4, 8, 16, 32 and 60 minutes. If a target stays silent for good, it is switched off after 20 failures, and the business is notified about that.

To the Standard Webhooks scheme: form the HMAC-SHA256 with the secret over webhook-id, webhook-timestamp and the unchanged body, and compare it with webhook-signature. Libraries for this exist for the common languages; you do not have to build it line by line.

Because a deleted client sets off a chain in the product that a receiver cannot follow. A reconciliation through the REST API is more honest there than a message that claims more than it carries. With time entries it is the other way round, so there is a delete event for those.

Yes, there is a test button on the target. It sends a delivery of type ping with a payload of its own, rather than a mislabelled business event. A receiver that processes by type therefore creates nothing that never existed.

Question not answered here? Every step is explained in the help centre.

Let your systems learn what happens in the business

Create a target, tick the events, send a test delivery. All of it in the company settings.

See the prices

No credit card, cancel any time

Related

Where to go from here, and what waits for you there.