Configure Greenhouse Native Candidate Webhooks

Greenhouse Recruiting candidate webhooks must be manually configured in the Greenhouse Dev Center to send events through Unified, which normalizes them into the `ats_candidate` format before forwarding them to an application’s public HTTPS endpoint. Setup requires an active Greenhouse connection, its connection ID, a Unified API key, appropriate Greenhouse webhook permissions, and separate native Unified subscriptions for created, updated, and deleted candidate events. Each resulting Unified subscription ID is used to construct a region-specific Unified endpoint that is entered into Greenhouse rather than the application’s own webhook URL. Greenhouse requires individual webhooks for each trigger, with creation triggers such as application or prospect creation mapped to the created subscription, candidate changes including hiring, rejection, stage changes, and updates mapped to the updated subscription, and candidate deletion or merging mapped to the deleted subscription. Greenhouse activates webhooks only after a successful test ping, and testing should verify receipt of normalized payloads containing the expected native webhook type, candidate object type, event, and candidate data, while deleted events provide the deleted candidate ID. Removal requires disabling or deleting both the Greenhouse webhooks and the associated Unified subscriptions, and troubleshooting focuses on endpoint accuracy, regional hostnames, permissions, active webhook status, trigger mapping, and idempotent handling of possible duplicate deliveries.

No tracked trend matches for this post yet.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.