SendOwl · AsyncAPI Specification

Sendowl Webhooks

Version

View Spec View on GitHub CompanyE-CommerceDigital ProductsPaymentsSubscriptionsCheckoutMembershipsLicensingCreator EconomyWebhooksAsyncAPIWebhooksEvents

AsyncAPI Specification

sendowl-webhooks.yml Raw ↑
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'