Overview

Applicant Status Webhooks let your system receive a real-time HTTPS POST from Double Nickel whenever an applicant's status changes — eliminating manual exports and letting your CRM, compliance tooling, or internal workflows react instantly when an applicant is hired, disqualified, moved to onboarding, and so on.

Event types

There is currently exactly one webhook event type:

Event type	`eventType` in the payload	Fires when
Applicant Status Changed	`applicant.status_changed`	An applicant's stage or sub-status changes

There is no separate hire-specific event. To act only on hires (or any other transition), subscribe to this event and filter on the payload — see "Filtering for the transitions you care about" below.

When deliveries fire

Any change to applicantStage (for example PROSPECT → HIRED).
Any change to the stage's sub-status, even when the stage itself does not change (for example hiringStage moving QUALIFICATION → ONBOARDING while the applicant stays in PROSPECT).
Applicant creation (the previous object then contains "applicantStage": null).

Two things to keep in mind:

Every active webhook configured for your company receives every status change — there is no per-status filtering on the Double Nickel side. Filter in your endpoint.
Webhooks are not sent for applicants whose automations are disabled in the dashboard.

Configuring webhooks

Log in to your Double Nickel dashboard.
Navigate to Settings → Integrations → Webhooks.
Click Add Webhook and provide your endpoint URL (must be HTTPS), an authentication type (None, Bearer token, or OAuth 2.0), and any optional custom headers.
Click Activate.

You can configure multiple webhooks for different use cases. There is no built-in test-send option today — to verify connectivity, change an applicant's status and confirm your endpoint receives the live notification. Partner sandboxes can do this safely in the Test environment (dashboard-test.getdoublenickel.com).

Delivery authentication

You can secure incoming deliveries in one of three ways:

Type	Description
None	No authentication header is added (you can still add your own static custom headers)
Bearer token (static)	You provide a static token during setup; Double Nickel includes `Authorization: Bearer <token>` on every delivery
OAuth 2.0 (client credentials)	You provide a `token_url`, `client_id`, and `client_secret`; Double Nickel obtains an access token before each delivery

OAuth 2.0 flow details

If you select OAuth 2.0 during setup, configure on your side:

A token endpoint (token_url) that implements the OAuth 2.0 client credentials grant.
The client_id and client_secret Double Nickel should use.
Optionally, any additional token-request parameters your identity provider requires (for example audience, scope, or resource) — these can be configured on the webhook.

Before each delivery attempt, Double Nickel sends your token endpoint a POST with Content-Type: application/json:

{
  "grant_type": "client_credentials",
  "client_id": "...",
  "client_secret": "...",
  "audience": "..."   // plus any other configured parameters
}

Your token endpoint must accept a JSON body (not only form-encoded requests) and return JSON containing an access_token field. A fresh token is requested for every delivery attempt — tokens are not cached. The webhook delivery then includes Authorization: Bearer <access_token>.

All webhook destinations must use HTTPS (TLS 1.2+). Stored tokens and secrets are encrypted at rest and masked in logs.

Example notification payload

{
  "eventType": "applicant.status_changed",
  "timestamp": "2026-08-27T15:12:22.145Z",
  "companyId": "3f9a1c2e-7b4d-4e8a-9c1f-2d6b8e0a4c73",
  "applicant": {
    "applicantId": "8c2d4f6a-1e3b-4d5c-9a7f-0b2e4c6d8f1a"
  },
  "data": {
    "applicant": { "applicantId": "8c2d4f6a-1e3b-4d5c-9a7f-0b2e4c6d8f1a" },
    "change": {
      "previous": { "applicantStage": "PROSPECT", "hiringStage": "ONBOARDING" },
      "current": { "applicantStage": "HIRED" },
      "changedAt": "2026-08-27T15:12:18.431Z"
    }
  },
  "metadata": {
    "environment": "production",
    "version": "1.0.0"
  }
}

What the payload contains — and what it doesn't. The payload identifies the applicant and describes the status change. It does not include application data or document URLs. To fetch those, use the applicantId and companyId from the payload to call the Get Applicant API (GET /applicant) and the Documents API (GET /documents).

Status values

applicantStage is always one of:

`applicantStage`	Sub-status key on the same object	Sub-status values
`PROSPECT`	`hiringStage`	`LEAD`, `APPLICATION`, `QUALIFICATION`, `ONBOARDING`
`HIRED`	— (none)	—
`DISQUALIFIED`	`disqualifiedReason`	Company-configurable values
`NOT_INTERESTED`	`notInterestedReason`	Company-configurable values
`TERMINATED`	`terminatedReason`	Company-configurable values

Treat the sub-status key as optional rather than assuming a fixed schema — the key name varies by stage, HIRED carries none, and previous.applicantStage is null for newly created applicants.

Filtering for the transitions you care about

Hires: data.change.current.applicantStage === "HIRED"
Moved to onboarding: current.applicantStage === "PROSPECT" and current.hiringStage === "ONBOARDING" — onboarding is a sub-status within PROSPECT, not a top-level stage.
Disqualifications: current.applicantStage === "DISQUALIFIED" (with the reason in disqualifiedReason)

Responding, timeouts & retries

Your endpoint should return an HTTP 2xx status code as quickly as possible — acknowledge first, then do heavy processing asynchronously.

Condition	System action
2xx response within the timeout	Event marked Delivered
Non-2xx response	Event retried
No response within the timeout (5 seconds per attempt by default)	Event retried
All retries failed	Event marked Failed and logged

Failed deliveries are retried up to 3 times with exponential backoff (4 total attempts). Every attempt is logged internally with the response status, body, and timing — if a delivery does not arrive, contact support and we can pull the delivery log for your endpoint.

Questions or need help?

For authentication and the REST endpoints, see Getting Started and the API & Webhooks FAQ.

Contact the Double Nickel support team at [email protected].