Webhooks for ticket changes

A webhook sends your tool a short message the moment a ticket is created or changes, so it does not have to keep asking. Your tool then reads whatever it needs through the API.

1. 1
   Open Webhooks

   A tenant admin opens Settings › Users and roles › API access › Webhooks and chooses Add webhook.
2. 2
   Give the address

   Paste your tool's address. It must be https on the standard port, use a host name rather than an IP address, and reach the public internet: Current refuses private, local and cloud metadata addresses. When the host name leads somewhere Current can't send, the answer is address_refused, the same for every cause; check that it is your tool's public address. A workspace can have at most 10 webhooks.
3. 3
   Pick the events

   ticket.created, ticket.updated, or both.
4. 4
   Copy the signing secret

   Current makes the endpoint's signing secret (it starts whsec_cur_) and shows it once. Store it beside your tool. Send a test checks the whole path with a ping event, up to 10 times an hour.

Ids and facts, never words: the ticket's id and number, its status and priority, its company, owner and board ids, its timestamps and, for ticket.updated, the names of the fields that changed. No subject, message text or email address is ever in a webhook. Read the ticket through the API when you need more.

{
  "id": "0e4b7c2a-6d19-4f83-b5a0-3c8e1d7f9a62",
  "type": "ticket.updated",
  "created_at": "2026-10-30T14:05:12.000Z",
  "api_version": "2026-10-31",
  "workspace_id": "7c1f4a9e-2b83-4d56-a0e7-9f3b5c8d1e24",
  "data": {
    "ticket": {
      "id": "6f1d2e8b-4c10-4a7e-9a52-0b8f2c5e3c1d",
      "number": 48213,
      "status": "waiting_customer",
      "priority": "normal",
      "company_id": "c2e9a0f4-1b7d-4c35-a8e6-5d3f7b1c9e02",
      "assignee_id": "8d4b6f1a-2c9e-4e73-b05d-7a1e3c5f9b48",
      "board_id": "5b3e8d2a-7c41-4f96-a0d7-1e9c6b4f2a85",
      "created_at": "2026-10-30T13:52:40.000Z",
      "updated_at": "2026-10-30T14:05:12.000Z"
    },
    "changed": [
      "status"
    ]
  }
}

Every message has a Current-Signature header: t= the time it was signed, and v1= an HMAC-SHA256, in hex, of the time, a full stop and the raw body. The key is the whole signing secret, whsec_cur_ included, as UTF-8 text; do not decode it. Your tool works out the same value, accepts the message when any v1 value matches, and compares in constant time. Refuse a message whose time is more than 5 minutes from your clock, so a copied message cannot be replayed later, and ignore an event id you have already handled.

# Check a saved delivery by hand: header.txt holds the Current-Signature value,
# body.json the body exactly as it arrived. The secret comes from the environment.
# openssl takes the key as an argument, which other people on the same computer can
# see in the process list while it runs: use this only on a computer you alone use,
# or check with the JavaScript or Python version, which never put the key there.
t=$(sed -E 's/.*t=([0-9]+).*/\1/' header.txt)
{ printf '%s.' "$t"; cat body.json; } \
  | openssl dgst -sha256 -mac HMAC -macopt key:"$CURRENT_WEBHOOK_SECRET"
# compare the result with the v1= value in header.txt

Rotate secret makes a new one. The old one keeps signing beside it for the time you pick (1 hour, 24 hours, 3 days or 7 days; 24 hours is the default). During the overlap a message carries two v1 values, one for each secret, so your tool can switch without missing any.

Messages for one webhook go out in the order the changes happened, but a retry can arrive after a newer message. Before you apply a ticket.updated message, compare its data.ticket.updated_at with the newest you have for that ticket, and skip an older one.

Your tool should answer with a 2xx status within 10 seconds. Anything else, a redirect included (Current never follows one), counts as a failure, and Current tries again after 1 minute, 5 minutes, 30 minutes, 2 hours, 6 hours, 12 hours and 24 hours. When your tool takes 5 seconds or more to answer twice, Current holds that webhook's messages back for a minute, then carries on in the same order.

After 3 days and 8 tries in a row without a delivery, Current switches the endpoint off and your tenant admins get a notification. Switching it back on keeps that count, so one more failed try switches it off again: fix your tool, switch the webhook on, then choose Send a test. A test that arrives resets the count.

The delivery log keeps 30 days of tries, with each answer's status code. Send again sends a failed or stopped message once more, while the webhook is on. It works for messages under 29 days old and up to 100 times an hour per workspace.