--- title: "Webhooks" slug: admin/webhooks url: https://projectri.com/docs/admin/webhooks section: admin audience: admin app_route: "/[slug]/admin/webhooks" permissions: [integration.view, integration.manage] mobile: false updated: 2026-09-08 source: Projectri documentation --- # Webhooks Push events out of Projectri to an address you own, signed, at least once, with a delivery history and automatic parking of a dead endpoint. ![Webhooks](https://projectri.com/docs-shots/admin-webhooks.png) ## What it is A webhook endpoint is an HTTPS address of yours that Projectri posts events to — task, project, sprint and milestone changes, tickets and escalations, time entries, invoices and estimates, and customer contacts. Each request is signed, each endpoint has its own secret, and the last few attempts are shown so "did you send it" is answerable without asking for your logs. ## How to get there **Work → Webhooks** in the admin console. Reading the list needs `integration.view`; creating, editing, rotating and deleting need `integration.manage` — a webhook can stream this workspace's tasks, tickets and invoices to an address of somebody's choosing, which is the same authority as connecting a third-party service. There is no plan gate. ## How to use it ### Add an endpoint 1. Enter an **https** URL with a public hostname. 2. Pick the event types you want, grouped as **Work**, **Support**, **Money & time** and **Customers**. Selecting nothing means you receive every event. 3. **Create endpoint**. 4. The **signing secret** is shown once, at the top of the page. Copy it. It is never displayed again, and there is no reveal button — a signing key readable from the console it is displayed in gives the signature nothing to prove. ### Verify a request Each request carries: ``` X-Projectri-Signature: t=,v1= ``` The HMAC-SHA256 is computed over `"."` with your endpoint's secret. Verify the timestamp as well as the digest — a signature over the body alone stays valid forever. ### Change which events an endpoint receives Press **Events** on the row and toggle the chips. Each toggle saves immediately. ### Rotate a secret **Rotate** asks first, then shows the new secret once. The old one stops working the moment you rotate, so anything verifying with it starts failing until you update it. ### Turn an endpoint off, or back on **Disable** stops delivery without deleting the endpoint. **Enable** resumes it and clears the failure counter — otherwise an endpoint the integrator has just fixed would be one failure away from being parked again by a count it accrued while it was broken. ### See whether delivery is working Each endpoint shows its recent deliveries with the HTTP status, the event type, any error and the time. The row header also states the consecutive failure count, and says plainly when an endpoint was switched off after repeated failures. ## What it affects - **Nothing inside Projectri.** Webhooks are outbound only; they read events, they do not write anything. - **Until one endpoint exists, no events are recorded at all.** The outbox is only populated when somebody is listening. - **Deleting an endpoint** stops delivery and takes its history with it. ## On mobile This screen is web only. ## Limits and gotchas > [!WARNING] > Delivery is **at least once**. The outbox is committed with the change and > published afterwards, so your consumer can see the same event twice and must > deduplicate on the `id` in the body. - **Only https, and only a public hostname.** `localhost`, `.local`, `.internal`, and bare IP addresses are refused, and redirects are not followed. This is the guard that stops the console being used to reach an internal address. - **Failures back off and then stop.** An event is retried up to six times with a widening delay, and an endpoint that fails twenty times in a row is switched off rather than retried forever. Re-enable it once the far side is fixed. - **An endpoint may subscribe to at most 100 event types.** Selecting none is the way to say "all", and is not the same as selecting them individually. - **The secret cannot be read back**, from this screen or the API. Losing it means rotating it. ## Related - [Integrations](/docs/admin/integrations) — connectors that push into a vendor's own product. - [Automation](/docs/admin/automation) — reacting to the same events inside Projectri. - [MCP and the API](/docs/features/mcp-and-api) — pulling data instead of receiving it. - [Security](/docs/admin/security) — API tokens, the credential for the pull direction. ## Related - [Integrations](https://projectri.com/docs/admin/integrations.md): Connect this workspace to the tools you already use, see which connections are healthy, and find the third-party applications somebody has authorised. - [Automation](https://projectri.com/docs/admin/automation.md): Rules that react to what happens in this workspace — a trigger, optional conditions, and an ordered flow of actions, waits and branches. - [Security](https://projectri.com/docs/admin/security.md): The sign-in rules this workspace enforces, who is signed in, what machine credentials and outside applications can reach it, and the sign-in history. - [The API, MCP and connected apps](https://projectri.com/docs/features/mcp-and-api.md): Three ways software reaches a Projectri workspace — the REST API, the MCP server for coding agents, and third-party apps a member authorises. - [Integrations](https://projectri.com/docs/features/integrations.md): The tools Projectri can connect to, what each connection actually does, how credentials are stored, and what a readiness badge means.