An automation runs when a record changes. As an org admin you attach one to an entity lifecycle event in API Studio; it then fires for every workspace in your org whenever a matching write happens.
Define an automation
You pick the entity, the operation (create or update), the stage (after), an event type, and a destination config. Optional entry_conditions gate when it fires.
POST /api/event
{
"entity_name": "Contact",
"event_name": "contact-created-push-salesforce",
"event_type": "external.connector",
"event_stage": "after",
"event_optype": "create",
"enabled": true,
"destination_config": {
"connector_id": "salesforce",
"action_id": "create-contact",
"field_mapping": { "Email": "{{source.email}}" }
}
}{{source.*}} is the changed record
In a destination config, {{source.field}} references the entity record that triggered the event. The mapping is resolved to concrete values before the handler runs.
Event types
- external.connector — call a registered third-party connector action.
- external.webhook — POST to a URL you specify directly.
- external.s3 — write an object to the tenant's own S3 bucket.
- notification.email / .slack / .sms / .teams — send a message.
- app.entity — write to another entity within the platform.
How it flows at runtime
Automations are driven by change data capture on the data store — your write path stays fast and the automation runs asynchronously.
Before-events vs after-events
After-events (covered here) run asynchronously once a write succeeds. A blocking before-event hook runs synchronously and can reject a create with 424 — use it for validation that must gate the write.