Events and webhooks
Provider callbacks are verified and normalized before they change Loresta state.
Contribution lifecycle
Section titled “Contribution lifecycle”Contribution lifecycle events reconcile dependent benefits, including granting or revoking Discord roles. Delivery attempts keep their provider status and receipt so retries remain idempotent and auditable.
Incoming callbacks
Section titled “Incoming callbacks”Provider-specific verification runs before a callback reaches workspace state. Invalid signatures or stale authentication context are rejected.
Incoming provider and payment callback routes are Loresta infrastructure. They are not public developer endpoints and must not be used as generic event ingestion URLs.
Outgoing webhooks
Section titled “Outgoing webhooks”Workspace owners and admins can create an outgoing webhook in Developer settings. Choose a creator profile, an HTTPS endpoint, and only the event families the destination needs. The signing secret is shown once, can be rotated, and is never returned again.
Loresta sends JSON with id, type, version, occurredAt, and a minimal data object. The available triggers are:
- Contributions:
contribution.completedandcontribution.refunded - Supporters:
supporter.createdandsupporter.updated - Goals:
goal.updatedandgoal.completed - Memberships:
membership.created,membership.updated, andmembership.cancelled
Supporter email, private messages, provider credentials, and payment credentials are not included.
Verify a delivery
Section titled “Verify a delivery”Each request includes webhook-id, webhook-timestamp, webhook-signature, and x-loresta-webhook-version. Version v1 computes HMAC-SHA-256 over <webhook-timestamp>.<webhook-id>.<exact UTF-8 body> using the one-time signing secret, encodes the digest as unpadded base64url, and sends it as v1,<digest>. Verify against the unmodified body before parsing or acting on it, reject timestamps more than five minutes from the current time, and store webhook-id so a retry cannot run the same action twice.
Secret rotation keeps the immediately previous secret available for in-flight verification. Update the destination first, verify a test delivery, then stop accepting the previous secret.
Event delivery guarantees
Section titled “Event delivery guarantees”Loresta records each attempt, response status, bounded retry, and uncertain outcome. A 2xx response completes the delivery. Rate limits and temporary endpoint failures retry with the same logical event ID. Redirects are not followed. Network failures after a request may have reached the destination are marked unknown instead of being retried blindly.
Developer settings shows recent delivery state and permits an explicit replay. Replays create a new delivery record while retaining the original event relationship, so the receiver must still use webhook-id for idempotency.
Zapier, Make, Activepieces, and n8n can receive the same HTTPS webhook contract. They receive signed, creator-approved event payloads only and never direct database or provider-secret access.