Ops Event Webhooks - Work New Tickets Automatically

Ops Event Webhooks let TATER Ops POST a signed event to an endpoint you control the moment a task is created, so an external automation can pick it up and start working it immediately instead of waiting for a schedule or a human to notice the queue.

When you would use this

• Route a newly submitted ticket to an automation that triages, enriches, or resolves it.
• Hand a ticket to an external agent runtime (for example a headless AI coding or ops agent) that has no inbound listener of its own.
• Fan task events into your own orchestration, queue, or workflow engine.

If all you want is a human alert in Teams or email, use Task Notifications instead. You do not need this feature for that.

How it works

1. You create a webhook subscription in TATER Ops and give it your endpoint URL, a secret, the event types you care about, and optional filters.
2. When a matching task event occurs, TATER POSTs a JSON body to your endpoint with an HMAC-SHA256 signature header.
3. Your endpoint verifies the signature, reads the task id from the payload, and does whatever you want with it.

TATER only emits the event. It does not run your automation. You supply the receiver. See Deploy a receiver below for a supported starting point.

Configure a subscription

Open TATER Ops, then Manage, then Connections, then Ops Event Webhooks.

1. Click + New subscription.
2. Endpoint URL: your HTTPS receiver. HTTP and private or internal addresses are rejected.
3. Secret: generate or paste a secret. It is shown once, then stored encrypted and redacted - only whether a secret is set is shown afterward. Save your copy in your own secret store at the same time.
4. Events: select the task lifecycle events to send. task.created is the one this guide focuses on. The same subscription mechanism can also carry control.failed, risk.accepted, incident.declared, and survey.responded - the events catalog shown in the subscription editor always reflects what your TATER instance currently supports.
5. Filters (optional): narrow by category and priority.
6. Save, then click Send Test to fire a sample payload and confirm your endpoint returns a 2xx.

The Delivery Log on each subscription shows recent attempts with timestamp, event type, status, HTTP response code, and a Resend action.

The loop guard - read this before you go live

Every task creation fires the event, including tasks your own automation creates through the API or MCP. If your receiver creates or updates tickets, it can re-trigger itself in a loop.

Protect against this in the subscription:

• Leave Exclude MCP-created turned on so tasks created by an AI or API agent do not fire the webhook. This is the primary guard and is on by default for every new subscription.
• Optionally scope by category or priority so only the queues you intend to automate fire events.

As defense in depth, also filter on the via field inside your receiver and ignore your own automation's source - the reference receiver below does exactly this.

Verify the signature

Every request includes:

• X-TATER-Event-Type - for example task.created. Branch on this if one endpoint handles multiple event types.
• X-TATER-Signature - sha256= followed by the HMAC-SHA256 of the exact raw request body, keyed with your subscription secret.

Compute the HMAC over the raw bytes of the body before any parsing, then compare in constant time. Reject the request if it does not match. A minimal example:

import hmac, hashlib

def verify(raw_body: bytes, header_value: str, secret: str) -> bool:
    expected = "sha256=" + hmac.new(
        secret.encode(), raw_body, hashlib.sha256
    ).hexdigest()
    return hmac.compare_digest(expected, header_value)

Node.js and PowerShell equivalents, and the complete field-by-field schema, are in the developer reference.

Payload shape

The body is JSON. The full schema is in the developer reference; the shape for task.created:

{
  "event": "task.created",
  "timestamp": "2026-07-03T14:32:00.000Z",
  "tenantId": "...",
  "organizationId": "org-...",
  "data": {
    "taskId": "task-...",
    "via": "web",
    "category": "IT",
    "priority": "High",
    "title": "OneDrive sync stuck",
    "status": "Open",
    "requesterEmail": "...",
    "assignedToEmail": "...",
    "dueDate": "2026-07-07",
    "url": "https://ops.tatersecurity.com/?page=task-detail&id=task-..."
  }
}

Treat taskId as the key. Your automation can call the TATER API or MCP to pull full task detail and to write results back as task comments.

Deploy a receiver

Your endpoint must be an always-on HTTPS service. TATER provides a reference receiver you deploy in your own tenant, parameterized by your organization id, API key, event subscription secret, and your automation runtime. The reference receiver:

1. Verifies the HMAC and rejects failures.
2. Applies a source (via) filter as a second line of defense.
3. Optionally queues the event so concurrent submissions don't collide.
4. Invokes your automation with the task id.

Download it from Docs > reference-runners > ops-event-webhook-runner. It ships in two forms - a bare Node.js process and an Azure Functions wrapper - pick whichever fits how you already deploy things.

If your automation is not safe to run in parallel, keep the queue step and drain it with a single worker - the reference receiver's README covers this.

Security notes

• The endpoint URL and the secret are both secrets. Do not paste them into tickets, chat logs, or source control.
• TATER accepts HTTPS public endpoints only and blocks internal or private targets.
• The secret is encrypted at rest and redacted on read. Only an admin can set a new one - nobody can read the existing value back.
• To rotate, set a new secret on the subscription, deploy it to your receiver, confirm delivery, then remove the old value from anywhere else it's stored.
• Every delivery is written to the Delivery Log, and every subscription change is written to the Activity Log / audit trail.

Troubleshooting

• No deliveries: confirm the subscription is enabled and the event type is selected. Check the Delivery Log for attempts and response codes.
• 401 or signature mismatch at your endpoint: you are almost certainly hashing the parsed body instead of the raw bytes, or the secret does not match. Recheck both against the signature verification guide.
• Deliveries arrive but nothing happens: your automation's own loop guard may be filtering them, or the receiver is not reaching your runtime. Check the receiver's logs.
• Runaway loop of tasks: confirm Exclude MCP-created is on, and add a source (via) filter in your receiver.
• A failed delivery didn't retry: TATER retries automatically up to 5 attempts with escalating backoff before marking a delivery dead-letter; after that, use Resend from the Delivery Log.

Related guides

• Ops Event Webhooks - Developer Reference - full payload schema, signature spec, and delivery/retry semantics
• Task Notifications - the human-facing Teams/email counterpart to this feature
• API Reference - authenticating your receiver's callback into the TATER API
• MCP Server Setup - what via: "mcp" means and why it's excluded by default