Webhook events

The catalog below lists every event type your registered webhook endpoints can subscribe to. Subscribe by including the event-type string in the eventTypes array when you create or update the endpoint. The platform’s live catalog is also available at GET /api/tenants/{tenantId}/webhooks/event-types — that endpoint is the source of truth and will reflect any catalog growth before this page does.

Every event fires when the underlying entity transitions through one of three actions:

• <entity>.created — a new row was inserted.
• <entity>.updated — at least one tracked column changed.
• <entity>.deleted — the row was soft-deleted (the platform never physically deletes domain entities).

Catalog

Event type	Fires when…
contact.created	A Contact is created (manually, via import, via API).
contact.updated	A Contact’s identity, primary address, or other tracked field changes.
contact.deleted	A Contact is soft-deleted.
order.created	An order is committed (cash, card, donation-only — all paths).
order.updated	Order status, totals, or fulfillment state change.
order.deleted	An order is soft-deleted.
order_donation.created	A donation line is added to an order.
order_donation.updated	A donation line’s amount or fund changes.
order_donation.deleted	A donation line is voided / removed.
order_payment.created	A payment row is attached to an order (charge, cash receipt, etc.).
order_payment.updated	A payment’s status changes (Authorized → Captured, refund recorded, …).
order_payment.deleted	A payment is voided.
batch.created	An accounting batch is opened (auto-batch or manual).
batch.updated	A batch’s counts, totals, or close state change.
batch.deleted	A batch is soft-deleted.
fund.created	A fund is added to the tenant’s catalog.
fund.updated	A fund’s name, processing-fee percent, or tax-deductible flag changes.
fund.deleted	A fund is soft-deleted.
donor_task.created	A task is created against a contact.
donor_task.updated	A task’s status, assignee, or due date changes.
donor_task.deleted	A task is soft-deleted.
recurring_donation_schedule.created	A recurring donation is set up.
recurring_donation_schedule.updated	Frequency, amount, payment method, or status changes.
recurring_donation_schedule.deleted	A recurring schedule is soft-deleted.
inventory_item.created	A new inventory item is added.
inventory_item.updated	Pricing, weight, bundle config, or other tracked fields change.
inventory_item.deleted	An inventory item is soft-deleted.
refund.created	A refund is processed against an order payment.
refund.updated	A refund’s status moves Pending → Processed / Failed.
refund.deleted	A refund record is soft-deleted.
shipment.created	A shipment is created (full or partial fulfillment).
shipment.updated	A shipment’s status, tracking, or carrier info changes.
shipment.deleted	A shipment is soft-deleted.

Status changes ride the updated event

There is no separate order.shipped or order.refunded event. Status transitions surface as order.updated (or order_payment.updated / shipment.updated) with the changed columns described in the body’s data.changes block. A receiver that only cares about a specific transition reads the changes:

import json

def handle(body: dict):
    if body["event"] != "order.updated":
        return
    changes = json.loads(body["data"]["changes"]) if body["data"]["changes"] else {}
    if changes.get("OrderStatus", {}).get("New") == "Shipped":
        # ...
        pass

Authorship signal

The data.user_id field carries the authoring identity:

• "<guid>" for tenant users (Identity user id).
• "api-key:<guid>" for events caused by API key calls.
• "system" (or empty) for background-service writes (recurring donation charges, ShipStation sync, scheduled report sends, etc.).

Use this when your replication layer needs to suppress events that your own integration caused.

Catalog growth

The catalog grows when new entity types become webhookable. When that happens, the live event-types endpoint surfaces the new strings the moment the API redeploys; this page lags. The breaking-change changelog gate does not trigger on catalog additions because they’re additive — but a coupled-path advisory prompts the docs to catch up.

Deliberate non-goals

• No restored action in the catalog. Soft-delete restores generate audit-log rows but aren’t surfaced as a webhook event today.
• No row-level filters. You can’t subscribe to “only orders > $1000” or “only contacts in Seattle.” Filter on the receiver.
• No backfill / historical replay. A new subscription only sees events from registration time forward.
• No payload-shape variations per event type. The wire shape is uniform; receivers switch on event and follow up with a read.