Connected recruitment workflows

Recruitment workflow integrations

When to use

When an ATS exchanges application changes, interview scheduling, assessments or approved hires with another service. Protect application identity and external effects throughout retries, delays and partial failures.

Workflow

1. Inspect the configured provider, installed connector/API version, enabled event types, credentials' scope and documented delivery behavior. Record the source of truth for candidate, job, application, interview and employment records. Map identifiers with organization and connection boundaries; never use a candidate ID as if it were an application ID.
2. Verify incoming webhook authenticity before trusting its fields. Use the provider's documented signature algorithm and header over the exact raw request body bytes; parsing and reserializing JSON can invalidate the signed representation. Use constant-time comparison and the correct connection secret. Validate timestamp/freshness when the provider's signature contract supplies it; do not invent a required timestamp field. Reject invalid signatures before business processing and keep secrets and full candidate payloads out of logs.
3. Persist a durable inbox record and deduplicate using the provider's stable event or delivery ID scoped to the connection. If no stable ID exists, document and test a provider-appropriate deduplication strategy; a candidate ID is not an event ID. Acknowledge only once the delivery is durably accepted, and track accepted, processing, applied and failed states so a crash cannot lose an acknowledged event.
4. Treat replay and ordering separately. A verified duplicate must not create a second interview or stage change. For out-of-order events, use documented revisions/effective times or fetch authoritative state; arrival time is not a business sequence. Replaying a historical event must not reopen a closed application or resend a candidate email unless that is an explicitly authorized new effect.
5. Keep state changes and outgoing work coordinated through the existing durable transaction/outbox mechanism. Use provider idempotency keys where supported and persist operation identity before sending. On timeout or a lost response after a write, mark the outcome unknown and query by stable operation/resource identity before retrying. Do not mark the effect successful merely because a request was dispatched, and do not blindly repeat a possibly-sent invitation or created offer.
6. Bound retries by failure type and provider limits. Respect rate-limit guidance, distinguish invalid credentials or withdrawn permissions from transient failures, and route exhausted or unreconcilable operations to visible human review with the safe replay procedure. For calendar flows, verify time zone, reschedule/cancel semantics and panel availability without creating duplicate meetings.

Evidence and verification

Deliver the event/field ownership map, signature validation evidence, idempotency boundaries and reconciliation procedure for the exact API version. Use a sandbox or authorized fixtures to test a valid signature, modified raw body, wrong connection secret, duplicate delivery ID, worker crash after acceptance, out-of-order stage event and timeout after a remote write.

Prove the visible business outcome and its count, not only a successful HTTP response: one intended interview, one application transition, or one approved HR handoff. Identify which external effects were simulated and which were actually verified. Keep event IDs, state and redacted diagnostics sufficient for recovery without retaining unnecessary applicant data.

Boundaries

• Integration does not authorize candidate communications, background checks, offers or hiring decisions. Use the authorization applicable to the actual effect.
• Do not expand recruiter permissions to make synchronization succeed. Preserve job-level and organization-level access and validate remote IDs before acting on them.
• Unknown outcomes remain unresolved until reconciled; retry exhaustion must not be reported as completion.

Primary references

Verify headers, signature rules, supported events and API behavior against the connected provider and version:

• https://docs.greenhouse.io/webhooks.html
• https://harvestdocs.greenhouse.io/reference/get_v3-applications