Event

trigger.workable_event

TriggerBusiness appsconnection requiredruns in-engine

Registers a subscription in the tenant's Workable account on publish and starts one run per delivered event, verified against Workable's signature.

Start a run when Workable raises an event (candidate, employee, job).

Ask about Workable All Workable nodes

Connection

Required: Yes — the node will not save without one
Auth type: Bearer token
Providers: Workable
Secret shape: the Workable SPI access token
Config it needs: subdomain
Resolved by: config.connection_id, else node.connection_id
Note: The token needs the r_candidates scope for candidate events and r_employees for employee ones. It is also the key Workable signs deliveries with, so rotating it invalidates the signature until the workflow is published again. Publishing needs MANTLE_APP_PUBLIC_BASE_URL set to an https URL Workable can reach.

Configuration

3 fields, none required. A dotted path is a nested object and name[] an array of objects — the editor renders the same tree.

Field	Type	Required	Default	Constraints	Example
event The Workable event to subscribe to. One subscription carries exactly one event — add a second trigger for a second event.	string	No	candidate_created	one of "candidate_created", "candidate_deleted", "candidate_moved", "employee_created", "employee_updated", "employee_published", "job_deleted", "onboarding_completed", "timeoff_updated"	—
job_shortcode Only receive candidate events for this job, e.g. GROOV005. Leave empty for every job. Workable's employee-side events ignore it.	string	No	—	≤ 64 characters	—
stage_slug Only receive candidate events for this pipeline stage, e.g. hired. Leave empty for every stage. Workable's employee-side events ignore it.	string	No	—	≤ 64 characters	—

Example configuration

Every value below is the contract’s own example or default — nothing invented.

{
  "event": "candidate_created"
}

Output

One shape.

workable event

The flattened Workable event. data's own keys vary by resource_type, so the shape is open below the declared fields.

Extra keys beyond the ones listed can appear.

Field	Type	Example
id Workable's event identifier. Also the idempotency key: Workable retries anything that does not answer 200 and repeats this id, so a retry joins the run it already started. The ingress remembers a key for 24 hours.	string	1b1c8399
event_type The event that fired, e.g. candidate_created. One subscription carries one event, so this is the event this trigger subscribed to.	string	candidate_created
resource_type What the payload is — candidate, employee or job.	string	candidate
fired_at When Workable raised the event, as an ISO-8601 UTC string. Not the delivery time, and not a reliable idempotency key — use id.	string	2024-05-30T12:00:00Z
resource_id The candidate/employee/job id, lifted out of data so the next node can fetch the full record without digging.	string	3fc9a80f
account_subdomain The Workable account the event came from, when the payload names one. Useful where one workflow serves several accounts.	string	groove-tech
data The resource itself, as Workable sent it. Its keys depend on resource_type — a candidate carries name/email/stage/job, an employee carries employment fields. Workable sends the resource's state at delivery time, which can be newer than when the event fired.	object	—
payload The envelope exactly as Workable sent it, for anything the fields above do not lift out.	object	—

{
  "account_subdomain": "groove-tech",
  "data": {
    "account": {
      "name": "Groove Tech",
      "subdomain": "groove-tech"
    },
    "email": "jj_botha@example.com",
    "id": "3fc9a80f",
    "job": {
      "shortcode": "GROOV005",
      "title": "Office Manager"
    },
    "name": "Jj Botha",
    "profile_url": "https://groove-tech.workable.com/backend/jobs/376/candidates/107",
    "stage": "Applied"
  },
  "event_type": "candidate_created",
  "fired_at": "2024-05-30T12:00:00Z",
  "id": "1b1c8399",
  "payload": {
    "event_type": "candidate_created",
    "id": "1b1c8399"
  },
  "resource_id": "3fc9a80f",
  "resource_type": "candidate"
}

Notes

Publishing creates the subscription in Workable; unpublishing, disabling or archiving deletes it. A workflow that is off is off at Workable too.
Workable allows one subscription per target URL, so two workflows never collide — each gets its own callback.
Subscriptions expire (Workable's own example is one year). The renewal sweep re-registers before that, which produces a new subscription id.
Workable sends the resource's state at delivery time, not at the moment the event fired, so a candidate moved twice quickly may arrive already in the second stage.

Related Workable nodes

See Event run in a workflow.

In a technical demo we add the Workable connection, drop the node on the canvas and let Workflow Health pre-flight it before the first real run.

Book a technical demo Talk to sales