ticket.created webhook delivers ticketNumber as 0 for tickets converted from conversations

We’re seeing ticket.created webhook payloads where data.item.ticketNumber is 0 instead of the real ticket number when the ticket is created by converting a conversation into a ticket.

A few seconds later, a corresponding ticket.updated webhook for the same ticket includes the correct nonzero ticketNumber.

This makes the ticket.created payload hard to use reliably for integrations that need the ticket number immediately, because the Tickets API uses the ticket number for GET /v2/tickets/{id} and PATCH /v2/tickets/{id}.

Observed behavior

• A conversation is converted into a ticket

• ticket.created webhook is sent with:

  • id: 69dbb88d9d1c1037d8e36e51

  • ticketNumber: 0

• ~2 seconds later, ticket.updated for the same ticket is sent with:

  • id: 69dbb88d9d1c1037d8e36e51

  • ticketNumber: 77

Expected behavior

• ticket.created should include the final valid ticket number even when the ticket is created from a conversation, or the docs should clearly state that ticketNumber may be temporary/zero at creation time.

Why this matters

• Integrations cannot safely use the ticket.created payload alone to fetch or update the ticket by ticket number.

• It forces an extra polling or lookup step to resolve the usable ticket number.

Example context

• ticket.created event time: 2026-04-12T15:21:49.779Z

• ticket.updated event time: 2026-04-12T15:21:52.194Z

• Same ticket object id in both events: 69dbb88d9d1c1037d8e36e51