Skip to main content

​
Transport

AspectSpecification
HTTP methodPOST
ProtocolHTTPS only
TimeoutResponse expected within 15 seconds
BatchingNot supported
OrderingNot guaranteed
Delivery semanticsAt-least-once
SuccessConsumer must respond with a 2XX status code

​
Retry behaviour

By default, TechWolf retries delivery when your endpoint returns one of these status codes: 408, 429, 500, 502, 503, 504, or when a request fails due to timeouts or other network errors.
  • Attempts: up to three retries per delivery
  • Backoff: exponential between attempts
  • Retry-After: if your endpoint responds with a Retry-After header, TechWolf uses that value (delay-seconds or HTTP-date per RFC 7231) instead of the default backoff

​
Source IP addresses

All webhook requests are sent from a fixed, static set of IP addresses. Allowlist the IPs for your region so that your endpoint accepts delivery from TechWolf. See IP Addresses for the current list.

​
Event format

All webhook payloads follow the CloudEvents 1.0 specification.

​
Base structure

{
  "specversion": "1.0",
  "type": "<event-type>",
  "source": "<resource-url>",
  "id": "<id>",
  "time": "<iso-8601-timestamp>",
  "data": {
    ...
  }
}

​
Field semantics

FieldDescription
specversionCloudEvents spec version (1.0).
typeEvent type and version; use to route the event and to know which API to call for the full state.
sourceURL of the resource that changed.
idUnique per event. Use to deduplicate, since delivery is at-least-once.
timeWhen the change occurred (ISO 8601). Useful for ordering or idempotency.
dataIdentifiers and metadata to locate the change and call the API (e.g. tenant, external_id, operation_type, external_vendor). Use these to fetch the full state from the API; the payload does not contain the resource itself.

​
Request headers

Unless you request or configure otherwise, each webhook request includes the following headers:
HeaderDescription
Content-Typeapplication/json
User-AgentTechWolf-Webhooks/1.0
X-Event-IdSame as the event id in the body; used when verifying the signature and for deduplication.
X-TenantTenant name; used when verifying the signature and when calling the API.
X-Signature-TimestampTime the message was signed (seconds since Unix epoch). Used when verifying the signature and to reject stale requests (replay protection).
X-Signature-V1Hex-encoded signature(s). May contain multiple comma-separated values during key rotation; at least one must verify.
See Security for how to verify the signature.