Events

Send custom events to trigger automations, exit enrollments, and feed your event log.

Custom events are the connective tissue between your app and Sendra's automations. When a user signs up, upgrades, or completes any meaningful action, send Sendra an event — automations whose Event received trigger matches that name will enroll the contact, and any active enrollment whose workflow lists the event in Exit on events will be dropped.

Sending an event

There are two ways to get a custom event into Sendra:

Inbound webhook (no code) — create an Event source in Settings → Events and point a third-party webhook (Stripe, your billing system, etc.) at the generated URL. Sendra maps the incoming payload to an email + event name for you. This is the easiest path and needs no authentication beyond the unguessable URL. See Event sources.
Direct API — POST /api/events/send, scoped to your workspace via your session. See the API reference for the full request and current auth model (workspace API keys are on the roadmap).

The direct call looks like this:

curl -X POST https://sendra.so/api/events/send \
  -H "Content-Type: application/json" \
  --cookie "$SESSION_COOKIE" \
  -d '{
    "email": "ada@example.com",
    "eventName": "signUp",
    "eventProperties": {
      "plan": "pro",
      "referrer": "newsletter"
    },
    "contactProperties": {
      "firstName": "Ada"
    }
  }'

Field	Required	Notes
`email`	yes	Lower-cased; auto-creates the contact if missing.
`eventName`	yes	The string automations match on. Recommended: camelCase, no spaces.
`eventProperties`	no	Arbitrary JSON; surfaces in the event log's Properties column.
`contactProperties`	no	Patches `firstName`, `lastName`, `name`, and any custom fields you've declared.

The response includes enrolled (how many automations enrolled the contact) and exited (how many active enrollments were dropped by the Exit on events rule).

Event sources

If you'd rather not write code, create an Event source under Settings → Events. Sendra gives you a unique inbound webhook URL — point any third-party service's webhook at it.

When you create a source you tell Sendra how to read the incoming payload:

Email path — where the recipient's email lives in the payload, as a dot-path (e.g. data.customer.email).
Event name — either a fixed name you choose (e.g. purchaseCompleted), or a dot-path to a field that holds the name (e.g. type).

Sendra extracts those fields from each delivery and runs the same ingest logic as the direct API — enrolling matching automations and applying exit events. Payloads it can't map are skipped (and reported), never dropped silently.

Event patterns

A pattern is a declared event name. Patterns power autocomplete in the trigger inspector, the dropdown filter in the event log, and serve as your in-app catalog of "what events does this workspace care about?"

You don't have to declare patterns before sending events — events flow regardless. Sendra flags events without a matching pattern as undeclared in the log and surfaces a one-click "Declare them" nudge on the Events page.

Pattern names must start with a letter and contain only letters, digits, _, ., or -. Max 120 characters.

Using an event as an automation trigger

In the automation builder, set the trigger type to Event received and pick a pattern (or type a new name — Sendra will offer to create the pattern inline).

Two frequency modes are available:

Every time (default) — every matching event creates a fresh enrollment. Use for re-engagement, weekly check-ins, anything cyclical.
One time per contact — only the first matching event ever enrolls a contact. Use for onboarding sequences.

Exit on events

The trigger inspector also exposes an Exit on events list. Any enrollment in this workflow is dropped the moment one of these event names arrives for the contact, regardless of which step they're on. This is the right place to short-circuit a 30-day re-engagement flow when the user finally signs in again, or to halt a trial-expiry sequence once the user purchases.

Event log

Open Settings → Events (the Events link in the sidebar takes you here) for a filterable log of received custom events. Filter by event name, contact email, or date range. The trigger inspector's Log → link deep-links here pre-filtered to the active event.

Naming conventions

A few patterns that tend to age well:

Use verbs in past tense for state changes: signedUp, upgraded, cancelled.
Use noun first for object-centric events: invoicePaid, seatAdded.
Avoid version numbers in names (signUp_v2). Add a property instead: { version: 2 }.
Don't include PII in event names. Keep secrets out of eventProperties too — they're rendered in the log.