Receive and verify requests
Headers, raw-body signature verification, retries, and dashboard test requests.
Checkout-session events
Complete session-created and session-completed envelopes and attribution keys.
Webhook catalog
Action IDs are the integers used when configuring a subscription (event_type). Actions 1–7 have no event name in their body and no X-WeGive-Event header. Their human labels/constants below are not additional JSON fields. Use separate receiver URLs or your subscription configuration to identify them.
Trigger details that affect reporting
Donation events (1, 2, 6): “new” or “updated” does not mean paid. Pending, processing, refunded, disputed, and other non-failed statuses can be delivered. An update whose resulting status is Failed is excluded, so this catalog is not a complete failed-payment notification feed. These events are not limited to browser checkout gifts and can also represent renewals, imported/offline gifts, or other creation paths that run model events. Updates contain a snapshot, not a changed-field diff. Donor events (3, 4, 5): the releasedDonor::updated implementation invokes actions 3 and 5, not 4. Treat action 3 as an upsert signal in this revision. Action 5 is the implemented create/update subscription. A successful dashboard test for action 4 proves receiver delivery only, not a working automatic update trigger. Donor webhooks are suppressed in bulk-import mode.
Recurring-plan event (7): this runs during saving, not after commit. It can occur on repeated/no-op saves. A new plan can have null id/timestamps and only currently assigned model attributes; a later database failure can occur after the HTTP call. Do not interpret every action-7 request as one newly persisted plan, or as a collected payment.
Session created (8): records creation of a session, normally when the checkout mounts; it is not proof of a distinct person or their first field edit. It applies across checkout configurations for the subscribed organization.
Session completed (9): correlates by the same session UUID. Repeated receipt updates do not normally create another completion event. Completion means a transaction or plan was attached; the trigger does not test transaction success status. A plan without an immediate charge also qualifies. The donor checkout’s receipt/session update supplies this linkage; if the donor leaves before that request, completion can be missing. There is no abandonment/expiry webhook in this catalog.