SendOwl · AsyncAPI Specification
Sendowl Webhooks
Version
View Spec
View on GitHub
CompanyE-CommerceDigital ProductsPaymentsSubscriptionsCheckoutMembershipsLicensingCreator EconomyWebhooksAsyncAPIWebhooksEvents
AsyncAPI Specification
generated: '2026-08-12'
method: searched
source: https://help.sendowl.com/help/using-web-hooks
spec_type: Webhooks
asyncapi_published: false
asyncapi_note: >-
SendOwl publishes NO AsyncAPI document — probed /asyncapi.yaml, /asyncapi.json on
api.sendowl.com and www.sendowl.com and searched the SendOwl GitHub organization; nothing found. The
event surface is documented in prose in the help center, so it is captured here as a webhook catalog
and wired as `type: Webhooks`. Nothing has been fabricated into AsyncAPI shape.
surface: outbound webhooks (HTTP POST from SendOwl to a merchant-supplied URL)
configuration:
url: https://dashboard.sendowl.com/settings/web_hooks
fields:
- name: Name (merchant's own label)
- name: Status (enable/disable)
- name: URL (destination the webhook is POSTed to)
- name: Event (the trigger)
conditions: >-
Additional conditions can narrow a webhook, including firing only when the order contains a
specific product.
transport:
method: POST
content: JSON body ("SendOwl webhooks post the order Liquid to your URL"), read from the raw request
body (e.g. php://input)
payload_root: order
payload_note: >-
The payload is the order object rendered from SendOwl's order Liquid template — transaction
details, buyer information and cart contents. SendOwl publishes no JSON Schema for it, so consumers
must infer the shape from the Liquid variable reference.
security:
signature_header: X-SENDOWL-HMAC-SHA256
algorithm: HMAC-SHA256 over the raw request JSON, base64-encoded
key: The Signing Key Secret from the SendOwl API settings page
documented: >-
"create a SHA256 digest using: The Signing Key Secret from your SendOwl API page as the key [and]
the request JSON as the data to digest" then base64 encode the result.
delivery:
success_codes:
- 2XX
- 3XX
retry: >-
"If any other code is returned (4XX, 5XX etc), we'll retry the request 10 times in an exponential
back off."
max_attempts: 10
backoff: exponential
ordering_guarantee: null
deduplication: null
note: >-
No event id, delivery id or replay/redelivery UI is documented, and there is no idempotency
contract, so a consumer must dedupe on order/transaction identity itself.
event_count: 14
events:
- name: Fraud review
category: order
- name: Free order issued
category: order
- name: In dispute
category: dispute
- name: New payment
category: payment
- name: Order charged back
category: dispute
- name: Order completed
category: order
- name: Order failed
category: order
- name: Order imported
category: order
- name: Refund issued
category: refund
- name: Subscription active
category: subscription
- name: Subscription cancelled
category: subscription
- name: Subscription cancelling
category: subscription
- name: Subscription complete
category: subscription
- name: Subscription setup
category: subscription
related:
polling_alternative: >-
GET /api/v1_3/orders?updated_after={ISO 8601 datetime} is the documented pull-based alternative for
keeping an external system in sync when webhooks are not viable.
source: https://dashboard.sendowl.com/developers/api/orders
gaps:
- No AsyncAPI or JSON Schema for the event payloads.
- No machine-readable event-name identifiers — the events are human-readable labels chosen in a UI
dropdown, not stable dotted event types.
- No signed-timestamp/replay-window guidance alongside the HMAC signature.
x-evidence:
- url: https://help.sendowl.com/help/using-web-hooks
http_status: 200
fetched: '2026-08-12'
- url: https://dashboard.sendowl.com/developers/api/orders
http_status: 200
fetched: '2026-08-12'