Event subscriptions

Wiring events to handlers: notify, queue a task, call a webhook.

Event subscriptions

What it is

The raw wiring under Automations: one row for each "when this happens, do that" in your business. An event is something Base records (a variation approved, a claim certified, a text received, 7am on a weekday); a handler is what runs (a notification, an assistant task, a webhook to another system). The Library explains each default in plain words with a switch; this tab shows every row as it is, including ones your team or the assistant made, and lets an admin build one by hand.

Before you start

  • The Automations module must be on for you.
  • Admin or team role. Anyone else is sent back to the dashboard.
  • For a webhook, the receiving system's HTTPS address and, ideally, a shared secret.
  • Most people never need this page. Ask the assistant instead: "when a variation over $5k is approved, make me an urgent task" creates the row for you.

How to

Find a subscription

Search by name, event type or handler (Search name, event type, handler), or filter by handler. Paused rows are hidden until you press Show paused; the defaults that are installed off on purpose always show. Each row reads as the event type → the handler, with a chip: on, off or paused.

Pause or resume one

Press the play/pause icon on the row (Pause / Resume; Turn off / Turn on for a default that ships switched off). The change applies immediately.

Create a subscription

  1. Press New subscription.
  2. Give it a Name and Description (both optional but worth filling; this is what you will read later).
  3. Pick the Event type from the grouped list. The names are the raw event names, such as project.variation.approved.
  4. Pick the Handler: Notification (in-app, email or SMS), Agent task (the assistant runs a prompt you write), Outbound webhook (Base sends the event as JSON to a URL), Workflow or Composite (several handlers in order).
  5. Set a Priority if order matters (higher runs first), an optional Filter (for example only amounts over 5000), and the Handler config. The form shows the shape each handler expects.
  6. Press Create.

The row appears, switched on, and fires the next time the event happens.

Edit one

Press the pencil. Name, description, priority, filter and handler config can change. The event type and handler type cannot; delete and recreate to switch them. Press Save.

Delete one

Press the bin, then Delete? within a few seconds to confirm. The row is gone for good. A deleted default is remembered so the hourly sweep does not put it back.

Replay a failed delivery

  1. Press the row to expand it. recent deliveries lists the last ten runs with their status, time, attempt count and error.
  2. On a failed or dead one, press Replay.

It is queued again from scratch and shows up in Activity.

Install or refresh the defaults

Press Install defaults. Every default Base ships is installed if missing and refreshed if its wording has drifted. Paused ones stay paused. To read what each does and turn them on one at a time, use the Library instead.

What happens on its own

  • When an event happens, Base writes it once, finds every active subscription for that event whose filter matches, and queues one delivery per match. A delivery retries up to five times with a growing wait before it is marked dead.
  • A delivery is marked dead at once if its subscription was paused before it ran or its handler no longer exists.
  • Once a day, deliveries that died in the last 48 hours are gathered into one review for the assistant, which replays what looks transient and notifies an admin about the rest.
  • An agent task runs on the assistant's background runner with the prompt you wrote. It drafts emails rather than sending them unless the subscription explicitly allows sending.
  • Nothing fires outward (webhook, email, SMS) for a sandbox project; those deliveries are held.
  • Outbound webhooks carry a signature header when you set a secret, so the receiving system can check the call came from Base.

Things that surprise people

  • Event names are the raw system names, not plain English. The Library row for the same automation has the plain words; use it to work out which event you want, then come here.
  • The form does not check a webhook URL or a handler config beyond "is it valid JSON". A mistake shows up as a failed delivery when the event fires, not when you save.
  • Event type and handler type are fixed once created. This is deliberate; a row that changed what it listened to would make its history meaningless.
  • Install defaults installs every missing default as on, including the AI ones. If you want only notifications, turn the rest on one at a time from the Library instead.
  • Two handler kinds (Internal task (dev) and DB action) belong to Base's operators and are not offered to customers.
  • Filters are and-ed. A filter with two fields matches only events that satisfy both.