Webhooks

DevStride POSTs a signed JSON event to your HTTPS endpoint the moment an item, comment or SLA timer changes, so your systems react in seconds instead of polling the API.

Webhooks push changes out of DevStride as they happen. You register an HTTPS endpoint and choose the events it cares about; whenever one of those changes happens anywhere in your organization, DevStride sends your endpoint a small JSON document describing it, signed so you can prove it came from DevStride.

Instead of asking the API "has anything changed?" every few minutes, your system is told, usually within seconds, and only when there is something to tell.

Why webhooks instead of polling

	Polling the API	Webhooks
How fast you hear about a change	Your polling interval, at best	Usually seconds
Requests when nothing changes	One per interval, forever	None
Counts against your API rate limit	Every poll	Never: DevStride calls you
Knowing what changed	Diff the results yourself	Each event says what happened, who did it and how
Missed changes while your system is down	Depends on your diff logic	Queued and retried for about a day, then replayable for at least 30 days

Webhooks and the API work well together: an event tells you that something changed and carries the essentials, and when you need the full record (a description, custom fields) you read it from the API by the ids in the event.

The events

Event	Sent when
`item.created`	A work item or Service Desk ticket is created, from any channel.
`item.status_changed`	An item moves to a different status.
`comment.created`	A comment is added to an item or ticket: public replies and internal notes alike.
`sla.at_risk`	A ticket is about to miss one of its SLA targets.
`sla.breached`	A ticket has missed one of its SLA targets.

The first three cover every work item in the organization; the two SLA events concern Service Desk tickets only. Every field of every event is listed in Events & Payloads.

What you can build

Sync tickets with a CRM or a partner's system. Mirror new tickets (item.created), their progress (item.status_changed) and the conversation (comment.created) into Salesforce, HubSpot or an outsourced support desk, without a nightly export.
Chat bots for Slack, Microsoft Teams or Discord. Post to a channel when an urgent ticket arrives or an item reaches a Done status, with your own formatting and routing rules.
Analytics and data pipelines. Stream every change into a warehouse (BigQuery, Snowflake, Redshift) or an event bus (Kafka, Amazon EventBridge) and measure cycle time to the second.
Automation platforms. Start a Zapier, Make or n8n workflow from their "catch webhook" trigger. Verify the signature in a code step where the platform offers one, or put a small verifying relay in front.
Audit trails. Keep an append-only record of who created and moved what, and when, in a system you control.
SLA escalation and paging. Turn sla.at_risk into a Slack warning and sla.breached into a PagerDuty or Opsgenie incident, so a missed promise wakes the right person.

How it works

Something changes in DevStride: an item is created, a status changes, someone comments, an SLA timer crosses a threshold.
DevStride builds one event for that change and queues one delivery for every enabled endpoint subscribed to that event type.
Each delivery is POSTed to its endpoint as JSON, signed with that endpoint's own secret. Deliveries to one endpoint go out one at a time, in order.
Your endpoint checks the signature, answers with any 2xx status, and processes the event.
If it does not answer 2xx in time, DevStride retries with growing waits for about a day. Everything is visible in the delivery log on the Webhooks settings page, where you can replay what failed.

The details are in Delivery, Retries & Ordering.

Webhooks or the "Call Webhook" automation action?

DevStride also has a Call Webhook action in Automations. They solve different problems:

	Webhooks (this section)	Call Webhook automation action
What triggers it	Every change of the subscribed types, organization-wide	One automation rule's trigger and conditions
Payload	A fixed, documented JSON contract	Text you compose from item fields
Signed	Yes, HMAC-SHA256 with a per-endpoint secret	No
Retries, ordering, delivery log, replay	Yes	No
Set up in	Configure Settings → Integrations → Webhooks	The automation builder

Use webhooks to keep another system in sync. Use Call Webhook for a one-off notification shaped by a single rule.

Who can manage webhooks

Everything on the Webhooks page, and every webhook API route, needs the Manage Webhooks permission (MANAGE_WEBHOOKS). The Owner and Admin roles hold it by default; you can grant it to a custom role in Roles & Permissions. It requires the Settings module. Members without it never see the page.

Grant Manage Webhooks with care

An endpoint receives events for every item and comment in the organization, internal notes included, regardless of what the person who set it up can see. For that reason the permission is not part of any permission template: applying the Manage org settings template to a role does not grant it. Give it only to people you would trust with an export of all your work.

Limits at a glance

Limit	Value
Endpoints per organization	20
Endpoint URL	`https://` only, at most 2,048 characters; private, loopback, link-local and cloud-metadata addresses are refused
Time to answer	10 seconds per request, 15 seconds in total including DNS lookups and redirects
Response body DevStride reads	64 KB (a larger response counts as a failure)
Delivery attempts	10, spread over about 24 hours
Signature timestamp tolerance	5 minutes (300 seconds)
Previous secret still valid after a rotation	24 hours
Comment HTML carried in `comment.created`	256 KB (larger comments arrive with `truncated: true`)
Delivery log retention	At least 30 days after a delivery was queued

Where to go next

Quickstart: a working, verified receiver in about ten minutes.
Events & Payloads: the envelope and every field of every event, with examples.
Verifying Signatures: the signing scheme and tested code in Node.js, Python, Go, Ruby, PHP and C#.
Delivery, Retries & Ordering: what counts as success, the retry schedule, ordering and health alerts.
Managing Endpoints: editing, disabling, rotating secrets, the delivery log and replay, from the app, the REST API or the MCP server.
Troubleshooting & Best Practices: building a receiver that never loses or double-counts an event.

Meetings

Pull Outlook calendar events and Microsoft Teams calls into Weekly Logs and log them against tasks in a couple of clicks.

Quickstart

Build a receiver that verifies DevStride's signature, register it under Settings → Webhooks, copy the one-time signing secret, send a test event and watch real deliveries arrive in the delivery log.