Webhooks

As jobs are added/updated/deleted in JobFront, you can subscribe to webhooks to get notified of key job events.

The jobs data structure returned via webook follows the same job data structure as in the api.

Webhook Event Types

JobFront can publish webhooks for the following events. Please note that webhook events are only triggered for jobs from sources/aggregators that you track and also for jobs that pass through your filters.

Job Created - event_type: "job_created" - New job created on your job board

Job Deleted - event_type: "job_deleted" - Job was deleted from the source, and subsequently removed from your job board

Job Updated - event_type: "job_updated" - Job was updated. This is uncommon; The most likely updates are changes to job titles.

Configuring Webhooks

You can configure webhooks in the JobFront app (https://app.jobfront.io)

Configuration requires a few fields.

Please note that we recommend leaving the Secret Key blank. This is a placeholder section in the webhook product feature right now, as we will add cryptographic verification soon.

Once configured, JobFront will submit a POST api call to the webhook URL you specified, when there are events that meet the events list you selected.

Example Webhook Event (Create - New Job Postback)

{
    "webhook_event_id":"E123",
    "created_at":1724003279,
    "event_data":{
    
        <job_object>
        
    },
    "event_type":"job_created",   
    "organization_id":"O123",   
    "updated_at":1724003279,
    "webhook_id":"W123"
}

Webhook Responses

Please return a 200 response when you receive a webhook, ideally within a few seconds. If your response takes longer than 5 seconds we will mark that webhook as having failed to deliver.

In practice, this likely means that you should set up a separate processing queue from your webhook response infrastructure.

Retries and Error Handling

If JobFront sends a webhook to your specified webhook url and we do not receive a response within 5 seconds, we will mark that webhook for retry.

JobFront will try to retry sending webhooks 3 times with exponential backoff.

A note on webhooks send order

We will try to send webhooks in the order in which changes our detected in our system. But we can't make a guarantee, especially when there are webhook retries.

Instead, please use the fields 'created_at', 'updated_at', and 'deleted_at" in the <job_object> payload of the webhook. These unix_timestamps will help you to keep track of change timestamps to jobs.

A note on webhooks send frequency

Currently, JobFront processes new jobs/updated jobs/deleted jobs for your account roughly every 6 hours. Over time the pause time between processing will decrease and approach 'realtime'. However what this means right now for webhook processing/sending is that you will receive batches of webhooks roughly every 6 hours. We try to space out webhook sending to avoid overwhelming your infrastructure, resulting in webhooks roughly every 1 second when we process the jobs queue from JobFront.

A note on timestamps (Webhooks)

Please see the note in the API page for more information about 'created_at' and 'updated_at' timestamps.

For webhooks, we also have 'created_at' timestamps for the webhooks. In those cases, it's an internal metric that helps us link together all the internal processing timestamps for when certain automated actions and services process the webhook events data and only loosely correlated with job post information such as updated times. You should always use the 'created_at' and 'updated_at' timestamps in the job object itself if you'd like to analyze the timestamps of the job postings themselves - and only use the webhook event timestamps for automated processing and validation checking purposes.