> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://developer.vitablehealth.com/webhooks/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://developer.vitablehealth.com/_mcp/server.

# Webhooks

## Docs

- [Events](https://developer.vitablehealth.com/webhooks/events.md): All webhook event types and when they are triggered.
- [Verifying Signatures](https://developer.vitablehealth.com/webhooks/signatures.md): Validate that webhook requests came from Vitable using HMAC-SHA512 signatures.
- [Reliability](https://developer.vitablehealth.com/webhooks/reliability.md): Retry behavior, circuit breaker, delivery guarantees, and best practices.


> **Note:** This page contains both a page directory (above) and the landing page content (below). The page directory is generated for agent use and does not appear on the landing page.

> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://developer.vitablehealth.com/webhooks/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://developer.vitablehealth.com/_mcp/server.

# Webhooks

> Receive real-time notifications when events happen in your Vitable integration.

Webhooks let your application receive real-time HTTP notifications when events occur in Vitable — such as an enrollment being accepted, an employee being created, or a payroll deduction being generated.

Instead of polling the API for changes, register a webhook endpoint and Vitable will `POST` event data to your URL as things happen.

## How It Works

1. You register a webhook endpoint URL with Vitable
2. When an event occurs, Vitable sends a `POST` request to your endpoint
3. Your server processes the event and responds with a `2xx` status code
4. If delivery fails, Vitable retries with exponential backoff

> **Tip**
>
> New to Vitable? Start with the [Employer Onboarding](/embedded_benefits/guides/employer-onboarding) guide to understand the full integration flow and when each webhook fires.

## Payload Format

All webhook events use a standardized payload schema:

```json
{
  "event_id": "wevt_550e8400-e29b-41d4-a716-446655440000",
  "organization_id": "org_xyz789",
  "event_name": "enrollment.accepted",
  "resource_type": "enrollment",
  "resource_id": "enrl_7c9e6679-7425-40de-944b-e07fc1f90ae7",
  "created_at": "2026-01-23T14:30:00+00:00"
}
```

**`event_id`** `string`
Prefixed identifier for this event (e.g., `wevt_...`). Use this for idempotency — your system may receive the same event more than once.

**`organization_id`** `string`
The organization this event belongs to. Use this to route events when managing multiple employers.

**`event_name`** `string`
The event type, formatted as `{resource}.{action}` (e.g., `enrollment.accepted`).

**`resource_type`** `string`
The type of resource affected (e.g., `enrollment`, `employee`).

**`resource_id`** `string`
The prefixed ID of the affected resource. Use this to fetch the current state from the API.

**`created_at`** `ISO 8601 (UTC)`
When the event occurred. All timestamps are in UTC.

> **Tip**
>
> The payload intentionally does not include a snapshot of the resource data. After receiving an event, call the corresponding API endpoint with the `resource_id` to get the current state. This ensures you always work with fresh data.