Subscription Controller

Introduction

The Subscription controller lets you subscribe to system events emitted by AdmiralCloud, enabling event-driven automation and integrations. A subscription defines which event to listen for, optional filter conditions (e.g. a specific customerId or payload value), and one or more instructions to execute when the event fires — such as calling an API endpoint, sending an email, or triggering a webhook.

Subscriptions can be created individually or from predefined templates. Once active, they run automatically in response to matching events, without requiring polling on your end.

Common use cases include triggering a workflow after an upload completes, notifying a team when a media container's status changes, or automatically releasing content when certain conditions are met. See the Event Service documentation for the full list of available events and example subscription structures.

Ownership & permissions

Every subscription has an explicit owner (ownerId), even when it was created on your behalf by another AdmiralCloud feature rather than through this API directly. This keeps event management predictable: only the owner of a subscription — or a user with elevated permissions — can update or delete it.

Two permission levels

If you only hold subscription.manageOwn:

• find results are automatically scoped to subscriptions you own
• update and destroy only succeed for subscriptions where ownerId matches your user id; any other subscription id returns subscriptionInvalid
• You cannot set or change ownerId on a subscription yourself — doing so returns ownerId_notAllowed

Subscriptions created indirectly

Some AdmiralCloud features create or modify a subscription as a side effect of another action. For example, configuring a Dropsite's upload notification creates (and later updates) an event:dropsiteUploadComplete subscription behind the scenes. In these cases:

• ownerId stays fixed to whoever originally triggered the subscription's creation and does not change on subsequent edits
• lastEditorId always reflects the user who most recently changed the subscription, even indirectly, so you get an accurate audit trail
• Access through this API (/v5/subscriptions/:id) is still governed by ownerId, not by who last edited it. A colleague can change the feature that owns the subscription (e.g. the Dropsite's settings) without becoming its owner, and without gaining the ability to manage it directly through this API — unless they hold subscription.manage

Deleting a subscription

By default, destroy soft-deletes a subscription (sets flag to 1); it is kept for history and audit purposes, along with its execution logs. Pass forceDelete: true to permanently remove the subscription and all of its logs instead. This cannot be undone.