Event triggers

An event trigger is what makes a workflow run when something happens somewhere else: a contact is created, a board item moves, a form comes in. You describe that in the interview the same way you describe everything else. "Run this whenever a contact is created in HubSpot."

It is one of the four shapes a trigger can take, and the one where the platform does the subscribing. The others are a schedule, an email trigger watching a mailbox, and a webhook URL the assistant mints for you to paste into the other service yourself. That last one is what a Framer form or a Zapier step gets, because there is no API there to subscribe against. This page is about the authored kind.

There is no catalogue, and that is the point

Most automation platforms answer "can it talk to X" from a list. If your service is on the list you get a trigger, and if it is not, you wait for somebody to add it.

All-Agents has no such list. Every service-event trigger is written during your interview, as code against that service's own API, for your workflow. The agent reads the service's webhook documentation, connects the credential with you, and writes the small piece of integration code that subscribes to the events. The platform then runs that code and keeps it working.

The consequence is the useful part: any service that speaks webhooks or can be polled is reachable, including the internal tool nobody else has heard of. The interview will never tell you a system is unsupported, because there is nothing for a system to be absent from.

There is a real cost on the other side of that. An authored integration takes interview turns where a hand-built one would have been a function call, and its quality depends on what the agent could learn from the service's documentation. The platform carries authoring notes for a handful of common services to make that first pass better. Whether a service has notes changes how quickly the agent gets it right, never whether it can be reached at all.

Two shapes of event trigger: subscribe, or poll

Which one you get depends on the service, and the agent picks it.

Webhook. The service supports subscriptions, so the trigger manages one. The platform mints a private inbound URL for your workflow, and the authored code tells the service to deliver events there. Three pieces of code exist for exactly this: create the subscription, check that it still exists, and delete it.

Poll. The service has no webhooks, so the trigger asks. A single piece of authored code fetches new items on a cadence, and a cursor remembers where it got to, so each item starts exactly one run even though the source is read again and again. The default cadence is every five minutes. A mailbox is the common case and the platform reads it itself, with no authored code at all; see Email triggers.

Either way, an event that arrives is turned into a run through the same path everything else uses. See Trigger payloads for what that run receives.

The credential stays out of the code

The trigger's code never holds your API key. You connect the service during the interview, either by signing in with the provider, by typing a key or an app password into a card, or by logging in through a real browser, and the platform stores that connection against your account.

When the trigger's code runs, the platform puts the credential in its environment, resolved under the connection's owner at the moment of the call. The code reads it from there. It cannot name a different connection, and it cannot be handed one as an input, so a key never ends up written into a code listing or a stored record of the call.

Publishing checks the connection behind the trigger itself before it arms anything; other systems the workflow names are not checked at publish, a missing credential there shows up on the first run that needs it, with a notification.

The inbound URL is a secret

An authored webhook trigger listens at a per-workflow address that includes a long random secret. The URL is the credential: anyone holding it can post events to that workflow.

Every request that does not match, including an unknown workflow, a paused one, or a nearly-correct secret, gets exactly the same 404 with no detail. A distinguishable answer would confirm which part was wrong.

A few answers are deliberately not that 404, and none of them tells the caller whether the trigger exists:

The size, rate and load limits are applied before the registration is even looked up, which is why they are safe to answer honestly. A delivery that gets through and is accepted is answered 202, and one the pipeline deliberately dropped is answered 200, because a 4xx would tell the service to keep retrying an event nobody wanted.

Two extra protections are declared as data rather than written as code, and the platform performs them itself:

• Signature verification. Services that sign their deliveries (an HMAC header, a shared token) have that checked on every inbound request, not only on the first. Rejections are counted and visible on the trigger rather than dropped.
• The registration handshake. Services that verify a new subscription by posting a challenge and expecting it echoed back get that answered automatically.

Neither is authored code, which means no tenant code runs on the public inbound path at all.

The secret rotates when the trigger is first armed, and again when you re-arm a paused workflow. It does not rotate on an ordinary re-publish, so a live URL stays stable. When it does rotate, the old subscription is removed first, so the service is never left delivering to a dead address. A webhook URL rotates on none of those, because you pasted it somewhere we cannot reach to update: only a deliberate regeneration changes it, and that rotates the auth token with it.

An armed trigger is a claim the platform keeps checking

Arming a trigger is not one API call that returned 200 once. The registration is a piece of desired state, and a background pass re-checks it roughly every five minutes.

• If the subscription still exists, nothing happens.
• If it has vanished, the platform re-creates it and sends you a heads-up that it briefly drifted. There is nothing for you to do.
• If it keeps failing, the trigger is marked as failed after three consecutive failures and you get one notification. A service that stays broken for an hour does not mail you twelve times.

A poll counts its failures the same way and ends differently. After three failed polls in a row you get one notification and the platform keeps polling rather than turning the trigger off, so a source that comes back starts working again with nothing to re-publish.

One rule is deliberately asymmetric. Creating and deleting a subscription change something on the other side, and a failure never says which side of the change it happened on. So a failed create or delete parks the trigger instead of being retried automatically, because the alternative is one bad trigger turning into a pile of duplicate subscriptions. Checking keeps running on a parked trigger, and publishing again is what releases it.

Where you see a trigger's health

The workflow workspace has an Apps tab with a Triggers section. Each armed trigger shows there with:

• the service it belongs to, and an authored chip when the integration was written by the agent;
• a status badge reading ok, drifted or failed, or off when the trigger is disabled;
• the inbound URL, for webhook triggers;
• a count of rejected deliveries, when signature verification has turned any away.

While an interview is open, the section shows the trigger the interview has drafted with an on publish badge, so you can see what will be armed before you arm it.

Lifecycle events also land in your notifications, under headings such as "Trigger re-armed" and "Trigger can't re-arm".

A broken trigger opens a repair, and you approve it

When a trigger crosses into failed, the platform reopens your interview and posts the failure into it. The agent works out what went wrong, proposes a corrected version of the integration code, and stops there.

You publish to apply it. Nothing about a trigger rewrites its own execution path, which is the same posture as everywhere else in the product.

One limit worth knowing: automatic repair needs an interview to reopen, and a codified workflow does not have one. A codified workflow with a broken trigger still notifies you, with a readable reason, but the repair is not proposed for you.

What an event trigger will not do

These are current limits, stated plainly:

• No event-type filtering. Arming a trigger subscribes to the stream the authored code subscribes to, and all of it routes to the workflow. Narrowing happens inside the workflow, not at the trigger.
• One workflow per trigger. An authored integration belongs to the workflow it was written for. A second workflow that needs the same events gets its own, authored again. Sharing one integration across workflows is not supported.
• A subscription slot the service says is taken stays taken. If creating the subscription comes back as a conflict, publishing fails and tells you, rather than taking the slot from whatever holds it.
• The authored code uses the standard library only. No third-party packages and no vendor SDKs, so HTTP calls are written out by hand.
• Running it by hand is refused. An event-triggered workflow has no event to invent, so the run button will not fire one. Use a test run with a sample payload instead.