Webhooks aus MetronHR empfangen

MetronHR meldet15 Ereignisse aus Zeiterfassung, Abwesenheiten, Personal und Schichtplanung an eine Adresse eurer Wahl, signiert nach Standard Webhooks. Ein Ziel abonniert einzelne Ereignisse, nicht alles. Enthalten im Professional-Tarif, ohne Aufpreis und ohne Mindestzahl an Lizenzen.

Stand:15. September 2026

Der Ereigniskatalog

Die Namen folgen dem Muster Ressource, Punkt, Vorgang, in derselben Schreibweise wie die REST-Adressen. Wer time-entries.created liest, weiß ohne Tabelle, dass die Nutzlast dieselbe Form hat wie die Antwort auf den Aufruf desselben Zeiteintrags.

  • Zeiteinträge

    Ereignisse
    created, updated, deleted
    Wofür ein Empfänger sie braucht
    Lohn und Projektcontrolling. Sie melden aus allen Erfassungswegen, auch vom Terminal und aus der App.

  • Abwesenheiten

    Ereignisse
    requested, approved, rejected, cancelled, updated
    Wofür ein Empfänger sie braucht
    updated ist der Fall, den ein Lohnsystem sonst übersieht: der Zeitraum eines bereits genehmigten Urlaubs verschiebt sich.

  • Mitarbeitende

    Ereignisse
    created, deactivated, updated
    Wofür ein Empfänger sie braucht
    Verzeichnisabgleich. updated trägt Abteilung, Rolle, Position, Personalnummer sowie Ein- und Austrittsdatum.

  • Schichten

    Ereignisse
    published, assigned, unassigned
    Wofür ein Empfänger sie braucht
    Zeitwirtschaft und Zutritt. Besetzungswechsel melden erst nach der Veröffentlichung, vorher ist die Planung ein Entwurf.

Stand 15. September 2026. 15 Ereignisse. Verbindlich ist das OpenAPI-Dokument der App, nicht diese Übersicht.

Der Rumpf einer Zustellung

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

Was eine Zustellung sicher macht

  • Signatur je Zustellung nach dem Verfahren Standard Webhooks: HMAC-SHA256 über Kennung, Zeitstempel und Rumpf, in den Kopfzeilen webhook-id, webhook-timestamp und webhook-signature.
  • Das Geheimnis lässt sich rotieren. Das alte signiert 24 Stunden lang mit, damit der Empfänger Zeit für den Wechsel hat.
  • Ein Ziel wird beim Anlegen gegen interne Netze geprüft. Eine Adresse im eigenen Netz nimmt der Server nicht an.
  • webhook-id bleibt über alle Wiederholungen gleich und ist damit der Idempotenzschlüssel des Empfängers.
  • Jedes Ziel abonniert einzelne Ereignisse, und ein Ereignis wird nur zugestellt, wenn der Betrieb die Ressource dafür freigegeben hat.

Wenn der Empfänger einmal steht

Ein Ausfall auf der Gegenseite kostet keine Meldung, solange er nicht zur Dauer wird. Die Zahlen sind gesetzt und nicht einstellbar, damit ein wartendes Ziel nicht zum stillen Rückstau wird.

  • Antwort dauert zu lange

    Was der Server tut
    Nach 10 Sekunden gilt der Versuch als gescheitert. Wer länger braucht, verarbeitet synchron; die Zustellung gehört in eine Warteschlange auf der Gegenseite.

  • Ziel antwortet mit einem Fehler

    Was der Server tut
    Bis zu 6 Versuche mit wachsendem Abstand: nach 2, 4, 8, 16, 32 und 60 Minuten. Die Kennung bleibt dabei gleich.

  • Ziel bleibt dauerhaft stumm

    Was der Server tut
    Nach 20 Fehlschlägen wird es abgeschaltet, und der Betrieb bekommt darüber eine Nachricht. Ein abgeschaltetes Ziel sammelt nichts nach.

  • Ziel wurde gelöscht

    Was der Server tut
    Wartende Zustellungen laufen aus, ohne weiteren Versuch.

Stand 15. September 2026. Ziele, Abonnements und der Testknopf stehen in den Unternehmenseinstellungen im Bereich Integrationen.

Webhooks sind der Weg nach draußen. Der Weg hinein ist die REST-API, und wer statt eines Systems einen Assistenten fragen lassen will, nimmt den MCP-Server.

Fragen zu den Webhooks

Was uns dazu am häufigsten gefragt wird.

Nichts zusätzlich. Ausgehende Webhooks gehören zum Professional-Tarif, wie die REST-API und der MCP-Server, ohne Aufpreis und ohne Mindestzahl an Lizenzen. Im Tarif Team sind sie nicht enthalten.

Ein POST mit JSON. Der Rumpf trägt Kennung, Art, Zeitpunkt des Vorgangs, den Mandanten und unter data dieselbe Form wie die Antwort der REST-API derselben Ressource. Ein Empfänger, der beides nutzt, hat einen Typ und nicht zwei.

Die Zustellung wird bis zu sechs Mal mit wachsendem Abstand wiederholt: nach 2, 4, 8, 16, 32 und 60 Minuten. Bleibt ein Ziel dauerhaft stumm, wird es nach 20 Fehlschlägen abgeschaltet, und der Betrieb bekommt darüber eine Nachricht.

Nach dem Verfahren Standard Webhooks: aus webhook-id, webhook-timestamp und dem unveränderten Rumpf den HMAC-SHA256 mit dem Geheimnis bilden und mit webhook-signature vergleichen. Bibliotheken dafür gibt es für die verbreiteten Sprachen; ein eigener Zeilenbau ist nicht nötig.

Weil ein gelöschter Kunde im Produkt eine Kette nach sich zieht, die ein Empfänger nicht nachvollziehen kann. Ein Abgleich über die REST-API ist dort ehrlicher als eine Meldung, die mehr behauptet, als sie trägt. Bei Zeiteinträgen ist es umgekehrt, deshalb gibt es dort ein Löschereignis.

Ja, am Ziel gibt es einen Testknopf. Er schickt eine Zustellung der Art ping mit einer eigenen Nutzlast, nicht ein falsch etikettiertes Fachereignis. Ein Empfänger, der nach Art verarbeitet, legt dadurch nichts an, was es nie gab.

Steht deine Frage nicht dabei? Schritt für Schritt erklärt ist die Bedienung im Hilfezentrum.

Lasst eure Systeme erfahren, was im Betrieb passiert

Ziel anlegen, Ereignisse anhaken, Testzustellung schicken. Alles in den Unternehmenseinstellungen.

Preise ansehen

Ohne Kreditkarte, jederzeit kündbar

Passt dazu

Wo es von hier aus weitergeht, und was dich dort erwartet.