Connect to your business workflow
with WhosOff webhooks

Webhooks with WhosOff

Webhooks are automatically triggered when key actions occur, including: Leave requests, approvals and cancellations, also Overtime requests, approvals and cancellations.

The moment any of these events happen, a structured JSON payload is securely delivered to your configured endpoint — allowing payroll, HR, time-tracking, ERP, or other integrated systems to react instantly.

Whether you're updating timesheets, triggering payroll adjustments, notifying managers, or synchronizing data across platforms, our webhook service ensures accurate, real-time communication without manual intervention.

How to setup Webhooks in your account

To set up the webhook, you'll need to be a Super User of the account. As a Super User you can access the webhook settings up via "Company Settings" on your account.

Sample object & structure

{ "event_id": "20",
  "event_type": "leave.created",
  "created_At": "2026-02-27 11:46:41",
  "data": { "id": "10049172", 
            "name": "Holiday",  
            "staff": "Hugh Zoff", 
            "approver": "", 
            "status": "pending", 
            "start_date": "2026-03-28 00:00",     
            "end_date":"2026-03-29 00:00"
          } 
}

Built-In security with WhosOff

Security is at the core of our webhook design. You can choose the verification method that fits your needs:

• Custom header key.
• A predefined shared secret is included in the request header for the above mentioned key.
• Quick and easy to implement.

For stronger protection, we support HMAC SHA-256 signature verification.

• A unique client secret is securely stored on both servers.
• Each payload is hashed using HMAC SHA-256 with the client’s secret, to create a unique signature. All signatures are sent in lower case.
• The resulting HMAC signature is sent in the used defined custom request header.
• The client independently recalculates the hash using: HMAC_SHA256(client_secret+raw_payload)
• If the computed hash matches the header signature, the payload is verified as authentic and untampered.

• Protects against tampering
• Prevents spoofed requests
• Ensures payload integrity
• Industry-standard security approach

HTTP status response codes

The HTTP status codes and their meaning are as follows:

Webhook Response & Retry Policy

To ensure reliable delivery while protecting your systems from unnecessary traffic, our webhook service includes a controlled retry mechanism.

When a webhook is sent to your endpoint, we expect an HTTP 200 OK response to confirm successful receipt and processing.

• We will make up to 5 delivery attempts per webhook event.
• If a 200 OK response is received at any point, delivery is considered successful and no further attempts will be made.
• If a non-200 response is returned — or if the request times out — the webhook will be retried.
• We wait 30 minutes between each retry attempt.
• After the fifth failed attempt, the webhook will be marked as undelivered, and no further retries will occur for that event.

To ensure smooth integration:

• Your endpoint should respond quickly (ideally within a few seconds).
• Always return HTTP 200 OK once the payload has been successfully validated and accepted.
• If processing takes longer, consider acknowledging the webhook immediately and handling the payload asynchronously.

This approach helps:

• Prevent duplicate processing
• Maintain predictable retry behavior
• Reduce unnecessary load on your systems
• Ensure consistent, reliable event handling