Built-in event families
The current catalogue includes lifecycle events for:- Storage create, update, synchronize, archive, restore, and delete;
- legacy File finalize, archive, and delete;
- User and Service Account create, update, activate, deactivate, restore, and delete;
- account API-key create, update, and delete.
custom boolean is the only API classifier. custom: true permits a dynamic business message; custom: false selects a supported platform lifecycle event and can only be replayed from existing history. Matching uses both type and custom, so identical names in different classes do not collide. The UI’s Internal control presents the inverse of custom.
Storage lifecycle cookbook
STORAGE_CREATED is emitted after the Storage record is durable and an upload is finalized. With computeStats: 'async', it can arrive before text statistics; subscribe to STORAGE_SYNCHRONIZED if the first Job must read cached batches immediately. Reports workspace lifecycle messages are not published as customer Storage events.
Use the Storage lifecycle types above. The legacy Files event producers are retired.
Available native event types
The Event editor retrieves the currently supported native types fromGET /api/v1/automation/event-types. The catalogue covers Storage, user,
Service Account and API-key lifecycle producers. It excludes unavailable autonomous inbox types. Previously saved types
remain visible for inspection; a catalogue loading failure disables type selection.
Disable Internal and enter Type for application-owned events.
API key expiry events
ACCOUNT_API_KEY_EXPIRING announces an upcoming expiry at a planned reminder
instant. ACCOUNT_API_KEY_EXPIRED is emitted when the key’s expiry becomes due.
The native lifecycle includes 7-day, 24-hour and expiry instants; authorized human
preferences can add first-reminder and custom automation-only offsets. Events
at an identical offset for the same key and expiry share one occurrence.
Notification email/System-message opt-out does not stop these events.
For a reminder one day before expiry, select
ACCOUNT_API_KEY_EXPIRING and add
this filter in the visual editor:
message.reminderDays. Add message.userId or
message.userKeyId to scope the integration. The target should reload current
key/account metadata under its execution principal and make its reaction
idempotent with noticeId. Do not assume that a replacement has already been
installed in the consumer merely because rotation created it.
Reminders are published when due, after current key-state validation. Revocation
or a changed rotation cutoff suppresses obsolete occurrences; uncertain account
changes defer processing. Existing-key adoption schedules future stages only.
Chain Component Jobs from execution outcomes
Use these native types to start a follow-up Job from a committed execution outcome:
These types cover ordinary Component Jobs. Cancellation, platform operations and Webhook delivery do not publish these events. Existing terminal Jobs are not replayed when the feature is enabled.
For a success chain, select
JOB_EXECUTION_SUCCEEDED, choose the follow-up Job template and filter by the source jobTemplateId. In the visual filter editor enter jobTemplateId; the API filter uses message.jobTemplateId. An unfiltered definition accepts outcomes from every matching Job template.
The message carries jobId and executionId for the source attempt, executionSeriesId for the execution series, jobTemplateId, name, category, status, completedAt, processingTime, executionUserId, initiatedByUserId, requestedFrom and retry context: retryRootJobId, retryParentJobId, retryAttempt, retryMode, retryScheduled, retryScheduledFor and final. Failed outcomes include a bounded errorCode and may include a processing recovery reason. Inputs, outputs, secret values, error messages and stack traces are excluded.
Automatic retries retain executionSeriesId. A manual retry starts a new execution series, while historical retry links and the attempt counter remain available. A final failure describes the automatic retry policy at that point; an operator can still retry manually afterward. The target executes with its configured principal and must load any source data it needs through authorized APIs.
Event delivery may be retried. Targets should make their business side effects idempotent. Lifecycle chains retain their Event-definition ancestry: a repeated definition is skipped with JOB_EVENT_CHAIN_CYCLE, and a chain beyond 32 definitions is skipped with JOB_EVENT_CHAIN_DEPTH_EXCEEDED. Event History records these skipped deliveries, including when replaying an outcome. Manual Job execution or manual retry starts fresh ancestry.
Continue with events.