Candidate Updates

By default, once a candidate has been sent to your integration, its data is final on Jobylon's side. If your integration needs to support edits (for example, when a client corrects a candidate's answers to your custom form), you can configure a separate update_url.

Once configured, Jobylon's ATS users will see a Re-send to {your integration} option on candidates already sent to you, letting them edit and resubmit the candidate's data.

This only applies to integrations that collect additional candidate-specific data through a form before sending (i.e. integrations using the candidate config endpoint). If your integration doesn't require that extra data, this feature does not apply.

Configuring update endpoint

update_url is configured the same way as your callback endpoint, please refer to Api Reference/OpenAPI

Because callback is a required field, you must always include your full existing config object (including callback, and fetch_config_url or company_settings if configured) when adding or updating update_url. Partial updates that omit callback will be rejected.

Update webhook payload

When a user edits and resubmits a candidate already sent to you, Jobylon sends the same candidate webhook payload documented in Webhooks, with action set to update instead of new, delivering it to your update_url destination. Apart from the action, the schema is identical to the new candidate event webhook.

Responding to results

Once you've processed the updated candidate, post your results back through the same candidate result endpoint you already use for new candidates. There is no separate results endpoint for updates.

Retries

Like all other webhooks, if your endpoint does not respond with a 2xx status, Jobylon will retry the request 3 more times with an exponential back-off.

Candidate Updates

Configuring update endpoint

Update webhook payload

﻿﻿Responding to results

Retries

Responding to results