Skip to main content

Introduction to Webhooks

Webhooks allow JobAffinity to notify your system when an application changes step. Notifications are sent in batches, within minutes of the change.

Available Events

The ProcessStepChange event is emitted each time an application changes step. If you need other events, let support know.

Configuration

To enable webhooks, contact Intuition-Software support: support@intuition-software.fr, providing the HTTPS URL of your endpoint. A single URL is configured per organisation. The notification body contains no personal data: only identifiers and links to the REST API. We recommend including an unguessable secret token in the URL (for example https://example.com/webhook/jobaffinity/7f3a9c2e...) and rejecting any call that does not carry it. If you have other needs (call authentication, signature, additional events), let support know.

Notification Format

JobAffinity sends a POST request with a JSON body:
  • _self, candidate._self, job._self: paths to prefix with https://jobaffinity.fr to fetch details via the REST API
  • id, candidate.id, job.id: identifiers of the application, the candidate and the job
  • step.name: name of the current step
  • step.status: position of the step in the process: START (first step), CURRENT (intermediate step) or END (final step)
  • step.date: date the application entered the step, in YYYY-MM-DD HH:MM:SS format
The notification describes the state of the application at the time it is sent. If an application changes step several times before the notification is sent, a single notification is emitted, carrying the latest step. Treat each notification as a signal that “this application has changed” and re-read its state via the API, rather than as an event log.

Webhook Call History

You can view the history of webhook calls made by JobAffinity.

Request

Response

Response Fields

  • id: identifier of the call, used for pagination
  • event: Type of triggered event
  • datetime: Date and time of the webhook call
  • response_status: HTTP status code returned by your endpoint, or 0 if the endpoint could not be reached (the error message is then in response_body)
  • response_body: Response body from your endpoint
  • application: Reference to the related application
This resource is paginated. Use the _next field to browse the complete history.

Implementing an Endpoint

Best Practices

  1. Respond quickly: Acknowledge the request, then process it asynchronously
  2. Return a 2xx code: The code and the first 1024 characters of your response are kept in the history
  3. Check the token: Reject calls that do not carry your secret token
  4. Make processing idempotent: Re-read the current state of the application via the API on each notification
  5. Log calls: Keep a record of received webhooks for debugging
Each notification is sent once. On failure (network error, non-2xx response), the call remains visible in the history with the response code and body.

Endpoint Example (Python/Flask)

Endpoint Example (Node.js/Express)

Monitoring

Use the webhook history to verify that your endpoint responds correctly, debug errors and audit received notifications. A response_status of 0 means your endpoint could not be reached; response_body then contains the error message.

Version Management

Webhooks follow the same versioning principle as the REST API. In case of major changes to the webhook format, you will be notified in advance.