NewEvery agent tool call now routes through the governed MCP gateway — policy check, audit log, then dispatch.Read the changelogarrow_forward
XOOZLYAI Orchestrator
routeHow it workssmart_toyAgent fleetshieldGovernance & trustsellPricingmenu_bookDocsarticleBloghistoryChangelog
Log inStart free
grid_viewProductsrouteHow it workssmart_toyAgent fleetshieldGovernance & trustsellPricingmenu_bookDocsarticleBloghistoryChangelogHelp centreLog in
Start free
  1. XOOZLY
  2. chevron_rightDocumentation
Loading the knowledge base…
XOOZLYAI Orchestrator

Ready to orchestrate your AI fleet with total confidence?

Start a project, set a cost cap, and watch the loop run with every tool call policy-checked and logged before it leaves the platform.

Start freearrow_forwardSee what shipped
  • check_circleNo credit card required
  • check_circleYour keys, your model spend
  • check_circleEvery tool call audited

Platform

  • All productsarrow_forward
  • Orchestration looparrow_forward
  • Agent fleetarrow_forward
  • Governed control planearrow_forward
  • Pricingarrow_forward

Trust & legal

  • Trust centrearrow_forward
  • Security & compliancearrow_forward
  • AI use policyarrow_forward
  • Report a vulnerabilityarrow_forward
  • Data subject requestsarrow_forward

Resources

  • Documentation & guidesarrow_forward
  • Engineering & research blogarrow_forward
  • Changelogarrow_forward
  • Uptime & reliabilityarrow_forward

Browse by domain

  • Strategy & Researcharrow_forward
  • Developmentarrow_forward
  • QAarrow_forward
  • Governance & Orchestrationarrow_forward
  • All 10 domainsarrow_forward
XOOZLY
© 2026 XOOZLY · 61 agents · 10 domains · 8 SDLC stationsAI use policyarrow_forwardLog inarrow_forward99.9% uptime SLAarrow_forward
  1. XOOZLY
  2. chevron_rightDocumentation
  3. chevron_rightGuide
Loading this guide…
  1. XOOZLY
  2. chevron_rightDocumentation
  3. chevron_rightWebhook signature verification and retry handling
arrow_backBack to the knowledge base
schedule2 min read·verifiedChecked against the code on 25 October 2026
MCP protocols & integrationswebhook-signatures-and-retriescodeapi-server/domains/webhooks/service.py

Integrations

Webhook signature verification and retry handling

XOOZLY has two webhook directions and they behave differently. Inbound deliveries are signature-verified on arrival; outbound deliveries retry on a bounded schedule and then stop, marked as exhausted rather than retried forever.

open_in_newOpen Webhooks in the consolearrow_forward
01

Inbound and outbound are not the same feature

“Webhooks” here covers two different things that behave differently, and conflating them is the usual source of confusion.

dangerousYOU RECEIVEVerified

Inbound

A request arriving from outside is verified against its signature before it is acted on. An unsigned or mis-signed request is refused — treat the signature as the whole credential.

shieldWE SENDBounded

Outbound

A delivery to your endpoint retries on a bounded schedule with exponential backoff, then stops and is marked exhausted. It does not retry forever, and an exhausted delivery is a thing you can see rather than a silent drop.

warningOne part is honestly incompleteThe “send a test event” control does not yet put a request on the wire — no outbound HTTP client is wired into that path. Registration, signature verification and the delivery records around it are real; treat the test button as not-yet-implemented rather than as evidence delivery works.
02

Verifying what you receive

An inbound delivery carries a signature computed over its body with a shared secret. Verify it before acting on the payload — the signature is the whole credential, so an unsigned or mis-signed request should be refused rather than logged and processed.

warningThe inbound receiver's secret is stored as givenUnlike provider API keys and connector credentials, the inbound signing secret is not encrypted at rest. That is a disclosed design note in the schema itself, not an oversight to discover later — treat the secret accordingly.
03

Outbound delivery and its retry schedule

A delivery to your endpoint is attempted, and on failure retried on a bounded schedule with exponential backoff. After the attempts are used up it stops and is marked exhausted — it does not retry forever, and an exhausted delivery stays visible rather than disappearing.

Attempts
3 retriesThen marked exhausted
Spacing
ExponentialBackoff between attempts
After that
VisibleNot silently dropped
04

The part that is honestly not built

science“Send a test event” does not reach the wireNo outbound HTTP client is wired into that path yet. Registration, signature verification and the delivery records around them are real; the test button is not evidence that delivery works.

boltPut it into practice

Run a fleet with these guardrails on from day one.

Hard cost caps, one audited gateway in front of every tool call, and versioned rule files — the defaults, not an enterprise add-on.

Start freearrow_forward

On this page

4 sections
  1. 1. Inbound and outbound are not the same featurechevron_right
  2. 2. Verifying what you receivechevron_right
  3. 3. Outbound delivery and its retry schedulechevron_right
  4. 4. The part that is honestly not builtchevron_right
feedbackSomething missing?

Related guides

  • articleThe MCP gateway: policy check, audit log, then dispatchMCP gateway policy editor
  • articleImporting and exporting MCP connector configurationsConnector config export & import
  • articleOAuth callback flows for third-party developer toolsOAuth callback debugger