Skip to main content
Webhooks let you subscribe to events in Orq.ai and receive an HTTP POST request to your server whenever those events occur, with no polling required.

Setting Up a Webhook

Navigate to Organization and select Webhooks. Click Create and configure the following:
  • Name: a unique name to identify this webhook
  • URL: the endpoint on your server that will receive the HTTP POST requests
  • Event types: choose which events should trigger this webhook
Webhook creation form with name, URL, and event type
fields
When deployment events are selected, an additional option appears:
  • Send me everything to receive events from all deployments
  • Let me select individual deployments to scope the webhook to specific ones.
After clicking Create, a Save your signing secret dialog appears with your secret. Copy and store it securely, as it will not be shown again. If you lose it, you will need to create a new webhook.
Use the signing secret to verify incoming requests.

Event Types

Orq.ai sends webhooks for the following events, grouped by resource:
GroupEvent
Agentagent.created
agent.updated
agent.deleted
Deploymentdeployment.created
deployment.updated
deployment.deleted
deployment.invoked
Promptprompt.created
prompt.updated
prompt.deleted
LLMllm.chat_completion
llm.response
llm.embedding
llm.rerank

Delivery Metrics

Webhooks dashboard showing delivery metrics, event deliveries chart,
response time chart, and endpoint list
The Webhooks page shows a Delivery Metrics dashboard with:
  • Total Deliveries, Successful, Failed, and Avg Duration over a configurable time range
  • An Event deliveries chart showing successful vs. failed deliveries over time
  • A Response time chart showing min, avg, and max response times
Each webhook endpoint is listed below with its URL, configured event types, and signing secret.

Payload Structure

All CRUD events share the same envelope. request_id is an optional string that identifies the originating API request. It is present when the event was triggered by a traceable API call, and absent for system-initiated events.

Agent

Deployment

Unlike CRUD events, deployment.invoked does not include workspace, project, api_version, or correlation_id. Deployment metadata is provided in a top-level metadata block instead of a nested object.
status is always present. It contains the HTTP status code returned by the upstream model provider (e.g. 200, 429, 500), useful for detecting partial failures without inspecting the full response.Several other fields are conditional and may be absent depending on the invocation:
  • contact_id: present when an Identity is linked to the request
  • billing: omitted when the response was served from cache
  • cache_status, cache_key, cache_config: present on cached responses
  • evals: present when Evaluators are configured on the deployment
  • thread: present when the invocation is part of a thread

Prompt

LLM

LLM events fire after the gateway processes a chat completion, response, embedding, or rerank call. The data block carries the OpenTelemetry GenAI semantic-convention span attributes so subscribers receive the full request and response payload inline. For the full list of orq.* attributes in the payload, see Span Attributes. The wire shape of gen_ai.input and gen_ai.output depends on which producer emitted the span:
  • For Responses API spans (llm.response), the canonical input/output is on openresponses.input / openresponses.output and is delivered as a JSON-encoded string.
  • For chat completion / embedding / rerank spans, the canonical fields follow OTEL GenAI semconv: gen_ai.input.messages / gen_ai.output.messages (chat), gen_ai.rerank.query / gen_ai.rerank.results (rerank).
  • The envelope’s top-level project field is omitted when the span has no associated project.

Best Practices

  • Use HTTPS: always use HTTPS for your webhook URL to ensure payloads are transmitted securely.
  • Verify signatures: validate the X-Orq-Signature header on every request before processing the payload.
  • Respond quickly: acknowledge receipt immediately with a 200 response. Offload any heavy processing to a background job.
  • Handle retries: if your endpoint is temporarily unavailable, Orq.ai may retry delivery. Make your handler idempotent using the event id to avoid processing the same event twice.
  • Monitor delivery: use the Delivery Metrics dashboard to track failures and response times.

Security

Every webhook request includes a signature you should verify before processing the payload.

Headers

HeaderDescription
X-Orq-SignatureHMAC-SHA256 hex digest of the request body
X-Orq-Hook-IDThe event ID
X-Orq-EventThe event type
User-AgentOrq-Webhook/2.0

How the signature is computed

The signature is computed over the exact raw request body bytes sent by Orq.ai. Verify the signature before parsing or modifying the body. Parsing and re-serializing JSON can change whitespace, field order, or number formatting and produce an invalid signature.
This is signed with your webhook secret using HMAC-SHA256 and hex-encoded. Always use constant-time string comparison to prevent timing attacks.

Verification examples