TL;DR: In part two and part three your app called into connected apps, one action at a time or through an AI assistant. App Events are the opposite direction: your product emits an event and ByteChef triggers your customers' workflows from it.
POST /api/embedded/v1/app-eventswith a free-form JSON body fans that payload out to every enabled workflow's app-event trigger for the current connected user. It's how "something happened in my SaaS" becomes "run the automations my customer built around it." This is part four of the series.
Half of embedded automation is your customers reacting to external apps (a new row in their Google Sheet). The other half, the half that makes your product the center of their automations, is reacting to events in your app. When a user upgrades their plan, closes a deal, or gets a new signup in your product, they'll want to automate what happens next. App Events are the inbound trigger that makes your product a first-class event source.
Emit an Event, Trigger Their Workflows
The playground is a single POST with a free-form body:
// POST /api/embedded/v1/app-events (bearer JWT)
await fetch('/api/app-events', { method: 'POST', body: JSON.stringify(eventPayload) });
On the ByteChef side, that call iterates every enabled integration the current user has, finds each workflow with an app-event trigger, and forwards your body as the event payload. One emit, fanned out to all the automations listening for it. The body shape is yours. It should match the JSON schema you defined for the event, so the workflows can map fields off it.
Put that in your product's backend, and every meaningful thing that happens becomes a potential automation trigger for your customers: subscription.upgraded, lead.created, ticket.resolved. You emit once; ByteChef routes it to whoever built a workflow around it.
See Every Run
Each workflow an event starts is a normal workflow execution, so it shows up on the Workflow Executions page under Embedded in ByteChef. You can filter by integration, workflow, status, and date range, and open any run to see the trigger payload your product sent and what each step did with it. When a customer asks "why didn't my automation fire?", that's where you look.
Why This Closes the Loop
Together, the ComponentKit and App Events make your product a full node in your customers' automation graph. Data flows both ways:
- App Events (in): your product's events start their workflows.
- ComponentKit (out): your app, or an AI assistant inside it, acts on connected services.
That bidirectionality is what turns "we have some integrations" into "our product is the hub." An event in your product can trigger a workflow that updates your customer's CRM, posts to their Slack, or calls back into your own API. ByteChef is the router in the middle, and App Events are your product's on-ramp to it.
What You Didn't Build
For one POST:
- An event ingestion endpoint that authenticates and scopes to a connected user.
- Fan-out routing to every matching workflow trigger across all the user's integrations.
- Payload delivery into the execution engine as trigger input.
- Execution history for every run the event started, on the Workflow Executions page.
No event bus, no subscription registry, no per-workflow dispatch. You emit; ByteChef routes.
What's Next
App Events start workflows implicitly: whoever's listening runs. Sometimes you want to invoke a specific workflow directly and get its result back. That's the next part, the Request Playground, where a workflow behaves like a synchronous API endpoint.
Following along? POST an event body to /app-events from your product's backend - every workflow your customers built around that event fires.
Top comments (0)