Webhooks
Webhooks let your backend react when activity happens in Mitu. Add a webhook endpoint, choose the events you want to receive and process each delivery in your own application as it arrives.
Webhook delivery is separate from requests Mitu forwards to your API on behalf of an AI agent. Webhooks notify your application that something has happened, while forwarded API requests are part of an agent using one of your product capabilities.
See Events for the event types and payloads available.
Configure a webhook endpoint
Create a webhook endpoint in the dashboard and provide the HTTPS URL that should receive deliveries. Each endpoint has its own webhook signing secret with the whsec_... prefix, which your backend uses to verify that incoming webhook requests were sent by Mitu.
Only subscribe an endpoint to the events your application needs. This keeps your handler focused and avoids processing unrelated activity.
Verify webhook deliveries
Every webhook request includes a signature header that your backend should verify before processing the event body.
The webhook secret belongs to the webhook endpoint that received the delivery. Keep it on your server and never expose it to browsers, mobile applications or AI clients.
whsec_... verifies webhook deliveries sent to your webhook endpoint. mps_... verifies requests Mitu forwards to your API when an AI agent uses one of your capabilities.
They protect different request flows and should not be used interchangeably. See Request verification for forwarded API requests.
Handle retries safely
Webhook delivery can be retried when your endpoint does not acknowledge an event successfully. A retry represents another delivery attempt for the same event rather than a new event, so every attempt keeps the same event_id.
Store processed event IDs and check them before applying side effects. This prevents the same event from creating duplicate records, sending repeated notifications or updating your state more than once.
Return a successful 2xx response after your application has accepted the event. Responses outside the successful range are treated as failed deliveries and can be retried.
If the current delivery policy remains five attempts with backoff, document that behaviour in your operational reference. Keep your application safe against duplicate delivery even if the retry schedule changes later.
Process events before responding
Verify the signature and determine whether the event has already been processed before applying the event to your system. For operations that must not be duplicated, persist the event_id together with the state change it causes.
If processing requires long-running work, acknowledge the webhook after safely recording the event and continue the heavier work asynchronously. Your endpoint should not rely on a long HTTP connection remaining open while downstream work completes.
Test your endpoint
Use the dashboard test capability to send a webhook delivery to your configured endpoint before relying on it in production. Process test deliveries through the same verification and event-handling code you use for normal webhook traffic so you are testing the actual integration rather than a separate development path.
Webhook delivery attempts should also be visible in the dashboard so you can inspect whether a request succeeded, failed or needs to be retried.