Webhooks

Receive real-time HTTP notifications when events happen in your server. Webhooks let you integrate Tixie with external tools, logging systems, and custom workflows.

Webhooks are a premium feature. You need an active premium subscription to create and manage webhook endpoints.

How Webhooks Work

When something happens in your server (a ticket is created, a setting is changed, etc.), Tixie sends an HTTP POST request to each webhook endpoint you've configured that subscribes to that event. The request body contains a JSON payload with the event type, timestamp, guild info, and event-specific data.

Webhooks are fire-and-forget from the bot's perspective — they never block ticket operations. Failed deliveries are automatically retried.

Creating an Endpoint

Navigate to the Webhooks page in your server's dashboard. Click Add Endpoint and fill in:

Name — a label to identify this endpoint (e.g., "Slack Integration")
URL — the HTTPS URL that will receive POST requests. Must be a public URL (private/internal addresses are blocked)
Events — which events to subscribe to. Leave empty to receive all events
Secret — an optional signing secret for verifying request authenticity (recommended)

Use HTTPS

Webhook URLs must use HTTPS. Internal, localhost, and private network addresses are blocked for security.

Event Types

There are 17 event types grouped into two categories. Select only the events you need, or subscribe to all events by leaving the selection empty.

Ticket Events

Event	Description
`ticket.created`	A new ticket was opened
`ticket.closed`	A ticket was closed
`ticket.claimed`	A staff member claimed a ticket
`ticket.unclaimed`	A staff member released a ticket claim
`ticket.status_changed`	Ticket status changed (Open, In Progress, Waiting, On Hold)
`ticket.assigned`	A ticket was assigned to a staff member
`ticket.tagged`	Tags were added or removed from a ticket
`ticket.note_added`	An internal note was added to a ticket
`ticket.message`	A message was sent in a ticket thread
`feedback.received`	A user submitted a feedback rating

Admin Events

Event	Description
`settings.updated`	Server settings were changed
`panel.created`	A ticket panel was created
`panel.updated`	A ticket panel was updated
`panel.deleted`	A ticket panel was deleted
`category.created`	A ticket category was created
`category.updated`	A ticket category was updated
`category.deleted`	A ticket category was deleted

Signature Verification

If you provide a signing secret when creating an endpoint, every delivery includes an X-Tixie-Signature header containing an HMAC-SHA256 signature of the raw request body. Always verify this signature before processing the payload to ensure the request came from Tixie.

Node.js verification example

const crypto = require('crypto');

const signature = req.headers['x-tixie-signature'];
const expected = 'sha256=' + crypto
  .createHmac('sha256', secret)
  .update(rawBody)
  .digest('hex');

const valid = crypto.timingSafeEqual(
  Buffer.from(signature),
  Buffer.from(expected)
);

if (!valid) {
  return res.status(401).json({ error: 'Invalid signature' });
}

Use the Raw Body

You must verify the signature against the raw request body string, not a parsed and re-serialized JSON object. Parsing and re-serializing can change whitespace or key ordering, which will cause the signature check to fail.

Request Headers

Every webhook delivery includes these HTTP headers:

Header	Value
`Content-Type`	application/json
`User-Agent`	Tixie-Webhook/1.0
`X-Tixie-Event`	The event type (e.g., ticket.created)
`X-Tixie-Signature`	HMAC-SHA256 signature (only if a signing secret is configured)

Delivery & Retries

Each delivery has a 5-second timeout. If your endpoint returns a non-2xx status code or doesn't respond in time, the delivery is marked as failed and automatically retried.

Retry schedule (3 attempts total with exponential backoff):

Attempt 1 — immediate
Attempt 2 — after 30 seconds
Attempt 3 — after 2 minutes
Final retry — after 10 minutes

If all retry attempts fail, the delivery is permanently marked as failed. You can view delivery status and error details on the Webhooks page in the dashboard.

Replaying Deliveries

From the Webhooks page, you can view the delivery log for each endpoint. Failed deliveries can be replayed — this re-sends the original payload to your endpoint as a new delivery attempt.

This is useful when your endpoint was temporarily down or had a bug that has since been fixed.

Limits

Limit	Value
Endpoints per server	5
Delivery log retention	30 days
Request timeout	5 seconds
Retry attempts	3 (plus initial attempt)

Payload Format

All webhook payloads follow the same structure: an event string, a timestamp in ISO 8601 format, a guild object with the server ID and name, and a data object containing event-specific details.