Webhooks API
The following sections have been provided to help in understanding the Webhooks API and how to configure it in Wordbee Translator:
Webhooks are used to connect Wordbee Translator to an outside CRM or other type of application. These calls retrieve information from Wordbee and send the information to an outside system at a defined time interval such as 30 minutes, 1 hour, etc. They may be used to create events on one website or application that invoke a specific behavior on another. In Wordbee Translator, webhooks may be used to push real-time information to a website or another application based on a configured status change for a Standard or CoDyt project. In order to configure a webhook, you must do the following:
Define the event to trigger the call.
Enter a valid URL for the request to be sent to.
Define the HTTP method: GET, POST, PULL, or DELETE. (For Wordbee it is typically a POST event).
Choose a content format.
Enter any additional fields or functions needed to complete the call.
A Webhooks API call might be performed when a project moves from an "in Progress" to a "Completed" status or when it changes from "Not Started" to "In Progress". Here are a few of the status change options offered by Wordbee for the Webhooks API:
Closed
Cancelled
Completed
Approved
In Progress
Not Started
Not Assigned
Proposal
When using the Webhooks API, you are able to define a status change for a type of project and then configure a URL and additional information for performing the required call.
How to Enable & Configure the Webhook API
To access the settings for enabling the Webhook API, first click on Settings in the Menu Bar and scroll down to the API section. Click on Configure to the right of Developer API Webhooks.
Next, click on Edit in the upper right corner to begin making changes:
First, choose the Webhook you want to use by clicking on the Webhook drop-down menu. This is the status change that will trigger the API call and as mentioned above many options are provided for both Standard and CoDyt projects.
Then enter the URL, select an HTTP method, and choose a content type (text or application). An HTTP body section is provided for entering additional field information. Click on See list of placeholders at the top of this screen to learn more. When finished, click on Save at the top of the entry window.
The saved information will appear similar to what is shown below:
Auto-disable for failing webhooks
When a webhook target stops responding (for example, the receiving server is moved, a Zapier zap is deleted, or an endpoint is permanently retired) Wordbee Translator does not keep retrying forever. After a number of consecutive delivery failures, the webhook is paused automatically. The webhook list shows a distinct badge so administrators can spot what happened, and re-enabling the webhook resumes deliveries once the endpoint is back.
When a webhook is automatically disabled
A webhook is paused automatically in either of these cases:
After 10 consecutive delivery failures. Each failed delivery increments a counter on the webhook configuration. As soon as a single delivery succeeds, the counter resets to zero. The webhook is disabled only when 10 failures occur in a row, with no successful delivery in between.
Immediately on an HTTP 410 Gone response. If the receiving server explicitly reports that the endpoint is permanently gone, the webhook is paused on the first such response, without waiting for the failure counter to reach 10.
When auto-disable is triggered, Wordbee stops scheduling further deliveries for that webhook. Events that occur while the webhook is disabled are not queued for later: they are simply not delivered. To resume deliveries, re-enable the webhook (see below).
Recognizing an auto-disabled webhook
The webhook list shows two distinct paused states:
DISABLED: an administrator manually unchecked the Enabled option on the webhook.
AUTO-DISABLED: Wordbee paused the webhook automatically after repeated delivery failures or an HTTP 410 Gone response.
When an administrator opens an auto-disabled webhook for editing, the page shows a banner explaining why the webhook was paused and pointing to the underlying error so it can be investigated.
Re-enabling a webhook
Once the endpoint is reachable again, resume deliveries:
Open the auto-disabled webhook from the webhook list.
Confirm or correct the URL if the endpoint has moved.
Check the Enabled option back on and Save.
Saving with Enabled checked clears the failure counter and removes the AUTO-DISABLED badge. Wordbee resumes delivering events that occur from this point onward. Past events that occurred while the webhook was paused are not retroactively delivered.
Changing the URL to a different endpoint also clears the failure counter, even if the Enabled option is left as-is. This handles the common case where a webhook was disabled because the endpoint moved: updating the URL alone is enough to give the new endpoint a fresh chance.
If the endpoint is permanently gone (for example, an obsolete integration), delete the webhook instead of re-enabling it.