Skip to main content

Webhooks: event notifications

Create a webhook, choose an event, verify requests from wxrks, and understand delivery, the delivery log and retries.

A webhook makes wxrks send an HTTPS request to your system when something happens, such as a project being created, a task being assigned or a translated file becoming ready. Use webhooks instead of repeatedly calling the API to ask whether anything changed.
​

💡 Who is this for? This guide is for the Account Admin who needs to create webhooks, and the developer who builds the receiving endpoint, within the wxrks platform.


How webhooks work

  • Each webhook watches one event. To be notified about several events, create one webhook per event.

  • When the event happens, wxrks sends a POST request to your Webhook URL with a JSON body.

  • Your endpoint must answer with any HTTP 2xx status within 3 seconds. Any other answer is recorded as a failed delivery.

  • When a delivery fails because your endpoint is unavailable or busy, wxrks retries it automatically. You can also retry any failed delivery from the delivery log (see Delivery log and retries).

Create a webhook

Only an Account Admin can create and manage webhooks.
​

  1. Go to Settings > Account Settings > Webhooks and stay on the Webhooks tab.

  2. Enter the Webhook URL. It must start with https://; Save stays disabled for http:// addresses.

  3. Optionally enter a Secret. wxrks sends it with every request so your endpoint can check where the request came from (see Verify that a request came from wxrks).

  4. Pick one Event.

  5. Click Save and confirm the dialog Do you want to save this webhook to <url>?

The Webhooks tab under Settings, Account Settings, Webhooks, with red boxes around the Webhook URL, Secret and Event fields and around the Status switch of the first webhook in the list

The webhook starts inactive

A new webhook is created Inactive. wxrks then sends up to 3 test requests (event WEBHOOK_VALIDATION), one second apart, and turns the webhook Active only if your endpoint answers with an HTTP 2xx status to one of them.
​

⚠️ Warning: If the test fails, wxrks does not show an error. The webhook just stays Inactive. After saving, check the Status switch of the new row, fix your endpoint, and turn the switch on. Only Active webhooks receive events.
​

💡 Tip: If your firewall filters incoming traffic, allow the IP address that the Webhooks page displays for wxrks requests (34.230.169.172 at the time of writing).
​

Create a webhook with the API

Send POST /api/v3/webhook with the fields url, type (the event name) and, optionally, secret. The same activation test applies. The response returns the new webhook (uuid, event, URL, creation date and status) without the secret, so keep your own copy of the secret when you create the webhook. See Authenticating with the wxrks API and the wxrks API documentation.
​

Events you can subscribe to

Every payload carries an event_type field with the event name. Each event name below links to an example payload in the wxrks API documentation.
​

Projects

  • NEW_PROJECT: a project was created.

  • NEW_EMPTY_PROJECT: a project without files was created.

  • PROJECT_UPDATE: the project's information was edited.

  • PROJECT_STATUS_CHANGE: the project's status changed. The payload includes previous_status and new_status.

  • PROJECT_INGESTION_COMPLETED: wxrks finished reading the project's files. The payload contains project_uuid, project_name and org_unit_uuid, plus workflows, target_locales and, when the project has one, ci_tag.

  • PROJECT_TRANSLATION_FINISHED: pre-translation finished. The payload includes total_work_units, total_work_units_completed and total_work_units_failed.

Tasks

Work units

  • WORK_UNIT_STATUS_CHANGE: a work unit's status changed (previous_status and new_status), with languages, file name, word and character counts, and whether it is the last workflow step.

  • WORK_UNIT_TRANSLATION_FILE_READY: the translated file is ready. The payload includes translated_file_url and original_file_url, which are temporary download links that stay valid for about 7 days.

Organizations, Organizational Units and users

Project, task and work unit payloads include the uuid of the project and the Organizational Unit, so you can match them to your own records.

Verify that a request came from wxrks

Every request carries these headers:
​

  • X-BWX-Event-ID: a unique ID for this event, kept on every retry. Use it to ignore duplicates.

  • X-BWX-Webhook-ID: the ID of the webhook that sent it.

  • X-BWX-Webhook-Secret: the Secret you saved, exactly as you typed it, or an empty value if you left it blank.

  • User-Agent: wxrks

Compare X-BWX-Webhook-Secret with the secret you stored, and reject the request if they differ:

if header "X-BWX-Webhook-Secret" != YOUR_SECRET: answer 401 and stop
if "X-BWX-Event-ID" was already processed: answer 200 and stop
answer 200, then process the event

ℹ️ Note: wxrks does not sign the request body, and does not send a timestamp, so a receiver cannot detect a replayed request. Keep the secret private, use a long random value, and accept requests only over HTTPS.

Delivery behavior

  • Success means any HTTP 2xx status, such as 200, 201 or 204.

  • Timeout is 3 seconds. Answer first and do the heavy work afterwards.

  • Automatic retries. If your endpoint answers 5xx, 408 or 429, or can't be reached, wxrks sends the event again up to 3 times: after 10 seconds, 1 minute and 2 minutes. Each automatic retry keeps the same X-BWX-Event-ID. Other answers, such as 400 or 401, are not retried automatically.

  • No ordering guarantee. Events can arrive out of order, so use fields such as new_status rather than the arrival order.

  • Duplicates are possible, for example when your endpoint processed an event but answered too late and wxrks retried it. Use X-BWX-Event-ID to ignore a delivery you already processed.

  • No automatic disabling. A webhook stays Active however many deliveries fail, so check the delivery log regularly.

Delivery log and retries

Open the Events tab on the Webhooks page. It lists every delivery attempt. Filter by webhook, event or result, and open Details to see what was sent and how your endpoint answered.
​

To send a failed event again yourself, click Retry on its row. A manual retry keeps the original X-BWX-Event-ID and adds an X-BWX-Retry-Of header with the ID of the original attempt. The test requests used when a webhook is created have no Retry button.
​

Through the API, GET /api/v3/webhook/events returns the same log (50 entries per page by default, up to 500), and POST /api/v3/webhook/events/{id}/retry retries one entry.

The Events tab of the Webhooks page, with a red box around the Webhook, Event and Result filters and the Refresh button
The Webhook Event Details window opened from the Details button of one delivery, showing the event, status, URL, response and payload

Choose which Organizational Units send events

Each Organizational Unit has an Enable Webhook Events switch on its Notifications tab, on by default. When it is off, project, task, work unit (including WORK_UNIT_TRANSLATION_FILE_READY) and Organizational Unit events for that unit are not sent. Organization and user events are not affected by it. See All about Organizational Units.
​

The Notifications tab of an Organizational Unit page, with a red box around the Enable Webhook Events switch

Webhooks or Pipelines?

A webhook sends the event's JSON as it is, with the three X-BWX headers, a delivery log, and automatic and manual retry. A Pipeline with an http action is a request you write yourself: you choose the URL, method (POST, PUT, DELETE or GET), headers and body, insert values from the event into them, and use Secrets for credentials. A Pipeline can react to more events than the 17 above, but it has no delivery log, no timeout setting and no retry, and a 4xx or 5xx answer does not fail the job. Use a webhook to tell another system that something happened, and a Pipeline to call a specific API with a custom request. See Getting Started with Pipelines in wxrks for the syntax.
​

Troubleshooting

  • The webhook stays Inactive after saving. Your endpoint did not answer with an HTTP 2xx status to the test request within 3 seconds, or it is not reachable from the internet. Fix the endpoint and turn the Status switch on.

  • No events arrive. Check that the webhook is Active, that it is subscribed to the event you expect (each webhook has one), and that Enable Webhook Events is on for the Organizational Unit.

  • The Events tab shows failed deliveries, but my system received them. Your endpoint answered after 3 seconds, or with a status outside the 2xx range. Answer right away with a 2xx status and do the processing afterwards.

  • I received the same event twice. Ignore the second delivery by checking X-BWX-Event-ID. Automatic and manual retries keep the same ID. A manual retry from the Events tab also carries X-BWX-Retry-Of, so you can recognize it.

Quick reference

Item

Value

Where

Settings > Account Settings > Webhooks

Who can manage

Account Admin

URL

HTTPS only

Events per webhook

One

Success

Any HTTP 2xx within 3 seconds

Retries

Automatic, up to 3 times (after 10 s, 1 min and 2 min) on 5xx, 408, 429 or no connection; manual from the Events tab or the API

Verification

X-BWX-Webhook-Secret header equals your secret; no body signature

De-duplication

X-BWX-Event-ID

Related articles

Did this answer your question?