Skip to main content
Webhooks in absentify allow you to call a script on your server whenever specific events occur in the absentify system. Acting as event listeners or push notifications, webhooks let you build integrations that respond to certain events, such as creating or updating requests, or managing users. When a subscribed event is triggered, absentify sends an HTTP POST request with relevant data to the specified webhook URL. This enables you to update external systems, send alerts, or automate actions based on changes in absentify.

​
Network requirements

If your webhook endpoint is behind a firewall, you need to whitelist the following IP address to allow absentify to send webhook notifications: Outbound IP address: 172.161.30.8 All webhook HTTP POST requests from absentify originate from this IP address.

​
Configuring webhooks

To set up webhooks, go to the Settings page in absentify.
  1. Log in and navigate to integrations Log in as an administrator, then click on Settings in the header, and select Integrations.
  2. Set the webhook URL Click on Configure URL and enter the URL where you want to receive event data.
  3. Choose event type From the dropdown menu, select the event type you want to subscribe to:
    • All Events
    • Request Created
    • Request Status Changed
    • User Created
    • User Updated
  4. Select payload version Choose the payload format version. We recommend using v2 for all new integrations.
  5. Save the configuration Click Add to complete the integration and start receiving notifications for the selected event types.

​
Payload versions

Webhooks support two payload formats:
VersionDescriptionStatus
v1Legacy formatDeprecated
v2Identical to Public API v1Recommended
v1 is deprecated. If you are still using v1, please migrate to v2. The v2 format is identical to the Public API v1 responses and provides more comprehensive data.

​
Event types

EventDescription
request_createdNew absence request created
request_status_changedStatus of a request changed
user_createdNew user created
user_updatedUser updated

​
Webhook payload structure (v2)

When absentify triggers a webhook, it sends a JSON payload with the following structure: 
{
  "event_type": "request_created | request_status_changed | user_created | user_updated",
  "body": { ... }
}
The event_type field indicates the specific event that triggered the webhook, and body contains the event data identical to the Public API v1 response.

​
Request events (request_created, request_status_changed)

See OpenAPI documentation: GET /api/v1/requests/{id} Fields:
  • id, createdAt, updatedAt
  • start, end, start_at, end_at
  • leave_unit, leave_type
  • status, approval_process
  • requester_member, request_creator_member
  • request_approvers (array with approver details)
  • workday_absence_duration, duration
  • reason, cancel_reason, canceld_date, canceld_by_member
  • take_from_allowance, allowance_type

​
User events (user_created, user_updated)

See OpenAPI documentation: GET /api/v1/members/{id} Fields:
  • id, custom_id, name, email
  • createdAt, updatedAt
  • status, approval_process
  • birthday, employment_start_date, employment_end_date
  • is_admin
  • departments (array with department details including manager_type)
  • allowances (array with allowance details)
  • allowance_type_configurations (array)
  • has_approvers (array with approver info)
  • approver_config (object with approver_type, custom_approvers)

​
Migration from v1 to v2

If you are still using v1 webhooks, please migrate to v2:
  1. Open webhook settings in absentify
  2. Edit the webhook
  3. Change payload version to v2
  4. Update your webhook receiver to handle the new structure:
    • Date fields use camelCase (createdAt instead of created_at)
    • Request data is flat (no details wrapper)
    • Approvers are in request_approvers (instead of approvers)
    • User data includes additional fields like has_approvers, approver_config, allowances
    • Departments include manager_type
The v1 format is deprecated. This section is only for reference if you need to understand the old format during migration.

​
Request events - v1 format

{
  "event_type": "request_created",
  "body": {
    "id": "string",
    "created_at": "2024-01-15T10:00:00.000Z",
    "updated_at": "2024-01-15T10:00:00.000Z",
    "start": "2024-01-20T00:00:00.000Z",
    "end": "2024-01-22T00:00:00.000Z",
    "start_at": "morning",
    "end_at": "evening",
    "leave_unit": "days",
    "status": "PENDING",
    "duration": 3,
    "reason": "string | null",
    "details": {
      "leave_type": {
        "id": "string",
        "name": "string",
        "icon": "string | null"
      },
      "requester": {
        "id": "string",
        "name": "string | null",
        "email": "string | null"
      },
      "request_creator": {
        "id": "string",
        "name": "string | null",
        "email": "string | null"
      }
    },
    "approvers": [
      {
        "id": "string",
        "status": "PENDING | APPROVED | DECLINED",
        "approver_member": {
          "id": "string",
          "name": "string | null",
          "email": "string | null"
        },
        "approved_date": "2024-01-15T10:00:00.000Z | null",
        "declined_by_member": {
          "id": "string",
          "name": "string | null",
          "email": "string | null"
        }
      }
    ]
  }
}

​
User events - v1 format

{
  "event_type": "user_created",
  "body": {
    "id": "string",
    "email": "string | null",
    "name": "string | null",
    "created_at": "2024-01-15T10:00:00.000Z",
    "updated_at": "2024-01-15T10:00:00.000Z",
    "public_holiday": {
      "id": "string",
      "name": "string"
    },
    "departments": [
      {
        "id": "string",
        "name": "string"
      }
    ],
    "status": "ACTIVE | INACTIVE",
    "microsoft_user_id": "string | null",
    "custom_id": "string | null"
  }
}

​
Key differences from v2

Aspectv1 (Legacy)v2 (Recommended)
Date fieldssnake_case (created_at)camelCase (createdAt)
Request structuredetails wrapper, approversFlat structure, request_approvers
User fieldsFewer fields, simple structureComplete including has_approvers, approver_config, allowances
DepartmentsOnly id, nameIncluding manager_type