Ably
DEVELOPER · DEVELOPER
Channels, message and presence history, and push notifications on their own key.
Acts as the person, not as itself
Each user connects their own account. Every call carries both identities — the agent and the person it is acting for — so the agent can never reach past what that individual can already do.
Credentials never touch the agent
Tokens live in the vault and attach server-side at call time. The agent holds a session, not a secret, and revoking access does not mean rotating a key.
Every call on the record
Who asked, which agent acted, which action ran, and the verdict that let it through — one audit trail across every integration, not one per vendor.
What an agent can do
Each action is granted on its own. An agent allowed to read is not thereby allowed to write, and the scope beside each row is what the acting user must have connected for it to run at all.
ably_control_delete_apps_by_app_id_namespaces_by_namespace_idWRITEDelete a channel rule (namespace) via DELETE https://control.ably.net/v1/apps/{app_id}/namespaces/{namespace_id}. Delete a channel namespace. The channels under that prefix fall back to the application's defaults immediately -- persistence, presence and push settings that the namespace was providing all stop applying -- and there is no undo. List the namespaces first and keep the settings: the reply to this call does not return them. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_delete_apps_by_app_id_queues_by_queue_idWRITEDelete a queue via DELETE https://control.ably.net/v1/apps/{app_id}/queues/{queue_id}. Delete a queue. Whatever is still sitting in it is discarded, consumers connected to it are disconnected, and any integration rule delivering into it starts failing. Check the rules on this app first: this call does not tell you which of them pointed here. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_delete_apps_by_app_id_rules_by_rule_idWRITEDelete an integration rule via DELETE https://control.ably.net/v1/apps/{app_id}/rules/{rule_id}. Delete an integration rule. Deliveries to its destination stop immediately and there is no undo -- recreating it needs the rule type, the source, the channel filter and the whole target configuration, which this call does not return. Read the rule first if it might need to come back. It affects the whole application, not only this connection: whoever relied on that delivery loses it. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_delete_apps_by_idWRITEDelete an app via DELETE https://control.ably.net/v1/apps/{id}. Delete an Ably application. THIS IS NOT REVERSIBLE AND IT IS NOT NARROW: the app's channels, API keys, integration rules, queues and namespaces go with it, and every client, device and server holding one of that app's keys stops working immediately. Ably offers no undelete. List the app's keys, rules and queues first if any of it needs to be recreated afterwards -- none of it is in this reply. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_get_accounts_by_account_id_appsREADList apps via GET https://control.ably.net/v1/accounts/{account_id}/apps. List every Ably application on the account, each with its id, name, status and settings (TLS-only, APNs environment, and the like). This is where an app id comes from: almost every other Control tool takes one in the path. `ably_control_get_me` returns this connection's account id, which is what account-level routes take in the path; an app id comes back from the create-app reply and is also the first segment of that app's API key. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_get_accounts_by_id_statsREADRead account statistics via GET https://control.ably.net/v1/accounts/{id}/stats. Read account-wide usage statistics: messages, connections, channels and API requests, aggregated across every app on the account. `id` is the ACCOUNT id, not an app id. `start` and `end` are milliseconds since the Unix epoch and are rounded down to the start of the `unit` interval (minute, hour, day or month); `direction` orders `backwards` (most recent first, the default) or `forwards`, and `limit` caps the page. `ably_control_get_me` returns this connection's account id, which is what account-level routes take in the path; an app id comes back from the create-app reply and is also the first segment of that app's API key. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_get_apps_by_app_id_keysREADList an app's API keys via GET https://control.ably.net/v1/apps/{app_id}/keys. List the API keys on one application, each with its key id, name, capabilities and creation time. Reading the capabilities is what makes this useful: an Ably key's power is fixed when it is minted, as a map of channel-name patterns to capability operations, and this is where you see what a given key can actually do. KEY MATERIAL IS REDACTED. Ably returns the complete API key (`appId.keyId:keySecret`) in the `key` field of every object this call answers with; Agentic Fabriq replaces that one field before the reply leaves the gateway, so a working data-plane credential never lands in a tool result, an audit event or a model's context. Everything else -- the key id, its name, its capabilities, its app -- is returned untouched, which is what the other key tools need. To read the key's value, open the app's API Keys tab in the Ably dashboard. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_get_apps_by_app_id_namespacesREADList channel rules (namespaces) via GET https://control.ably.net/v1/apps/{app_id}/namespaces. List an application's channel namespaces -- Ably calls them channel rules. A namespace is a channel-name prefix (`chat` matches `chat:room1`) carrying the settings that apply to every channel under it: whether messages are persisted, whether presence is enabled, whether push is enabled, whether the channel is TLS-only. This is the call that explains why a channel behaves the way it does -- message history, for instance, exists only where persistence is on. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_get_apps_by_app_id_queuesREADList queues via GET https://control.ably.net/v1/apps/{app_id}/queues. List the application's Ably-hosted message queues, each with its name, region, AMQP and STOMP connection details and current state (message counts, whether it is approaching its limits). A queue is where an integration rule of type `amqp` delivers, so this is the other half of the rules picture. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_get_apps_by_app_id_rulesREADList integration rules via GET https://control.ably.net/v1/apps/{app_id}/rules. List the application's integration rules -- the standing subscriptions that forward Ably messages, presence events and channel lifecycle events out to somewhere else: a webhook, a serverless function, an Ably queue, an AWS or Kafka or Pulsar target, or a content-moderation vendor. READ THIS BEFORE CREATING ONE: a duplicate rule means every matching message is delivered twice. A rule's `target` may itself contain credentials for the third-party system, so treat this reply as sensitive. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_get_apps_by_app_id_rules_by_rule_idREADRead an integration rule via GET https://control.ably.net/v1/apps/{app_id}/rules/{rule_id}. Read one integration rule by its id: its type, its source, its channel filter, its status and its full target configuration. The target may contain credentials for the third-party system the rule delivers to, so treat this reply as sensitive. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_get_apps_by_id_statsREADRead app statistics via GET https://control.ably.net/v1/apps/{id}/stats. Read one application's usage statistics: messages, connections, channels and API requests over a time range. `start` and `end` are milliseconds since the Unix epoch, rounded down to the start of the `unit` interval (minute, hour, day or month); `direction` orders `backwards` (the default) or `forwards`. `id` is the APP id. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_get_meREADRead this connection's access token details via GET https://control.ably.net/v1/me. Read the details of the access token this connection authenticates with: the capabilities it holds, when it expires, when it was last used, and the Ably user and ACCOUNT it belongs to. Two reasons to call it first. (1) It is where the account id comes from, and the account-level routes take that id in the path; nothing else in this integration returns it. (2) ABLY CONTROL API ACCESS TOKENS EXPIRE -- the dashboard's creation dialog offers 30, 60 or 90 days or no expiration and DEFAULTS TO 30 DAYS -- and once one expires every Control call answers 401. `expires_at` here is how far away that is. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_patch_apps_by_app_id_keys_by_key_idWRITEUpdate an API key via PATCH https://control.ably.net/v1/apps/{app_id}/keys/{key_id}. Change an existing API key's name or capabilities. NARROWING A CAPABILITY TAKES EFFECT IMMEDIATELY for every client already using that key, so a key in production stops being able to do whatever you removed as soon as this returns -- read the key first and send the capability map you mean in full, because this replaces it rather than merging into it. KEY MATERIAL IS REDACTED. Ably returns the complete API key (`appId.keyId:keySecret`) in the `key` field of every object this call answers with; Agentic Fabriq replaces that one field before the reply leaves the gateway, so a working data-plane credential never lands in a tool result, an audit event or a model's context. Everything else -- the key id, its name, its capabilities, its app -- is returned untouched, which is what the other key tools need. To read the key's value, open the app's API Keys tab in the Ably dashboard. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_patch_apps_by_app_id_namespaces_by_namespace_idWRITEUpdate a channel rule (namespace) via PATCH https://control.ably.net/v1/apps/{app_id}/namespaces/{namespace_id}. Change a channel namespace's settings. It takes effect for every channel matching that prefix and for every client of the application. Turning `persisted` off stops new messages being stored (and existing history ages out on its own schedule); turning `pushEnabled` off breaks push subscriptions on those channels. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_patch_apps_by_app_id_rules_by_rule_idWRITEUpdate an integration rule via PATCH https://control.ably.net/v1/apps/{app_id}/rules/{rule_id}. Change an integration rule -- its status (`enabled`/`disabled`), its channel filter, its source or its target. ALWAYS SEND `ruleType` IN THE BODY, even when you are only changing one other field: the PATCH body is a discriminated union and `ruleType` is its discriminator. Measured 2026-09-18 -- `{"status": "disabled"}` alone answers 400 `discriminator propertyName ruleType does not exist in value`, while `{"ruleType": "http", "status": "disabled"}` answers 200. Read the rule first to learn its `ruleType`. Disabling is the reversible way to stop a delivery; changing the target repoints an existing stream of the application's messages somewhere else, which is the same side-channel decision as creating one. Third-party credentials in a target arrive here as tool arguments and are recorded in the audit trail. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_patch_apps_by_idWRITEUpdate an app via PATCH https://control.ably.net/v1/apps/{id}. Change an Ably application's settings -- its name, its status (`enabled` or `disabled`), `tlsOnly`, and its Apple Push Notification service environment. Setting `status` to `disabled` stops the app serving every client at once, which is a whole-application outage rather than a configuration nudge. Uploading an APNs `.p12` certificate is a separate multipart route that this integration does not carry. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_post_accounts_by_account_id_appsWRITECreate an app via POST https://control.ably.net/v1/accounts/{account_id}/apps. Create an Ably application on the account. `name` is required; `status`, `tlsOnly` and the APNs fields are optional. The app comes back ENABLED and immediately usable -- there is no review or pending state -- and its reply carries the new app id. A new app has no API keys you can use from this integration until one is created, and this integration redacts key material out of the create-key reply, so the first key's value is collected from the Ably dashboard. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_post_apps_by_app_id_keysWRITECreate an API key via POST https://control.ably.net/v1/apps/{app_id}/keys. Mint a new API key on one application. `name` labels it and `capability` is a map from channel-name pattern to the operations that key may perform there -- for example `{"orders:*": ["publish", "history"], "chat": ["subscribe"]}`. The measured vocabulary is `publish`, `subscribe`, `presence`, `history`, `stats`, `channel-metadata`, `list-channels`, `push-subscribe`, `push-admin`, `privileged-headers`, `object-publish`, `object-subscribe`, `annotation-publish`, `annotation-subscribe`, the `message-*` update and delete operations, `presence-subscribe`, `message-subscribe`, `channel-metadata:publishers`, and `*` for all of them. THIS CREATES A WORKING CREDENTIAL that outlives this connection and is not bounded by anything Agentic Fabriq grants: give it the narrowest capability that does the job, and remember that whoever receives it can use it until it is revoked. KEY MATERIAL IS REDACTED. Ably returns the complete API key (`appId.keyId:keySecret`) in the `key` field of every object this call answers with; Agentic Fabriq replaces that one field before the reply leaves the gateway, so a working data-plane credential never lands in a tool result, an audit event or a model's context. Everything else -- the key id, its name, its capabilities, its app -- is returned untouched, which is what the other key tools need. To read the key's value, open the app's API Keys tab in the Ably dashboard. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_post_apps_by_app_id_keys_by_key_id_revokeWRITERevoke an API key via POST https://control.ably.net/v1/apps/{app_id}/keys/{key_id}/revoke. Revoke an API key. Ably's own wording is 'this deletes the key': it stops working at once, everywhere, for every client holding it, and it cannot be restored -- a replacement is a NEW key with a new value. CHECK WHICH KEY THIS IS FIRST. If it is the key this integration's own Ably Pub/Sub connection authenticates with, revoking it breaks that connection too, and the failure will read like a wrong credential rather than like this call. The reply carries no key material. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_post_apps_by_app_id_namespacesWRITECreate a channel rule (namespace) via POST https://control.ably.net/v1/apps/{app_id}/namespaces. Create a channel namespace (channel rule) on an application. `id` is the channel-name prefix it matches and the flags -- `persisted`, `pushEnabled`, `presence`, `presenceSubscribers`, `tlsOnly`, `exposeTimeserial` and the rest -- decide how every channel under that prefix behaves. THIS AFFECTS EVERY CLIENT OF THE APPLICATION, not only this connection: turning persistence on starts storing message history for those channels, and turning push on is what makes push channel subscriptions possible there at all. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_post_apps_by_app_id_queuesWRITECreate a queue via POST https://control.ably.net/v1/apps/{app_id}/queues. Create an Ably-hosted queue on an application. `name`, `region`, `ttl` (seconds a message survives undelivered) and `maxLength` (how many messages it will hold) are the shape of it. The reply carries the AMQP and STOMP URIs a consumer connects with. Queues are billed and capped per package -- a create that fails on a limit says so. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_control_post_apps_by_app_id_rulesWRITECreate an integration rule via POST https://control.ably.net/v1/apps/{app_id}/rules. Create an integration rule: a standing subscription that forwards matching Ably events to a destination you name. `ruleType` picks the target family (`http`, `http/zapier`, `http/ifttt`, `http/cloudflare-worker`, `http/azure-function`, `http/google-cloud-function`, `aws/lambda`, `aws/kinesis`, `aws/sqs`, `amqp`, `amqp/external`, `kafka`, `pulsar`, the ingress rules and the moderation rules), `source` picks what it listens to (`channel.message`, `channel.presence`, `channel.lifecycle`, `channel.occupancy`) and `channelFilter` is a regular expression narrowing which channels it applies to. TWO THINGS TO WEIGH BEFORE CALLING THIS. First, the rule is a PERSISTENT SIDE CHANNEL: from the moment it exists, every matching message leaves the Ably application for the destination, for every user of the app, until the rule is deleted. Second, several target types take THIRD-PARTY CREDENTIALS in the request body -- an AWS access key id and secret access key, a Pulsar token, Kafka SASL credentials, a Postgres or MongoDB connection string -- and anything in a tool argument is recorded in Agentic Fabriq's audit trail. Prefer a target that authenticates by role or by URL secret where the choice exists. PLANE: Ably CONTROL API (https://control.ably.net/v1). This tool needs an Ably ACCOUNT ACCESS TOKEN -- the credential the 'Control API access token' connection method collects -- and an Ably app API key will not work on it (measured: a valid app key answers 401 on every Control route). If this connection was made with an app key, Agentic Fabriq refuses the call by name rather than forwarding it to be answered with a bare 401.
ably_platform_delete_push_channelsubscriptionsWRITEDelete push channel subscriptions via DELETE https://rest.ably.io/push/channelSubscriptions. Delete push channel subscriptions matching a filter -- the devices or client ids in it stop receiving push for that channel. `channel`, `deviceId` and `clientId` narrow it. (Ably's deprecated contract labels this operation 'Delete a registered device's update token', which is wrong: measured 2026-09-18, it deletes channel subscriptions, and the update-token route it names no longer exists at all.) AT LEAST ONE FILTER IS REQUIRED, and Agentic Fabriq enforces it. Ably's contract declares every filter on this route optional, which means a call with none of them deletes EVERY matching record on the whole application rather than nothing. A call that names no filter is refused here before any request is sent. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_delete_push_deviceregistrationsWRITEUnregister matching push devices via DELETE https://rest.ably.io/push/deviceRegistrations. Unregister push devices matching a filter, and delete their channel subscriptions with them. `deviceId` unregisters exactly one; `clientId` unregisters EVERY device registered against that client identity. Devices unregistered here stop receiving push notifications immediately and the registration cannot be restored from this reply -- the device has to register again, which normally means the app running on it. AT LEAST ONE FILTER IS REQUIRED, and Agentic Fabriq enforces it. Ably's contract declares every filter on this route optional, which means a call with none of them deletes EVERY matching record on the whole application rather than nothing. A call that names no filter is refused here before any request is sent. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_delete_push_deviceregistrations_by_device_idWRITEUnregister one push device via DELETE https://rest.ably.io/push/deviceRegistrations/{device_id}. Unregister ONE push device by its device id, and delete its channel subscriptions with it. It stops receiving push notifications immediately and the registration is not recoverable from this reply; re-registering normally means the Ably SDK on the device doing it again. Measured 2026-09-18: answers 204 with an empty body. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_get_channelsREADList active channels via GET https://rest.ably.io/channels. List the application's currently ACTIVE channels -- channels with at least one connection, or with something else keeping them alive. A channel nobody is attached to is not listed, so an empty reply means nothing is live rather than that nothing exists; `[]` is the normal answer on a quiet app (measured 2026-09-18). `prefix` filters by channel-name prefix, `limit` caps the page, and `by` chooses what comes back (`value` for the full occupancy detail, `id` for names only). PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_get_channels_by_channel_idREADRead a channel's metadata via GET https://rest.ably.io/channels/{channel_id}. Read one channel's metadata: whether it is active, and its occupancy -- how many connections, publishers, subscribers and presence members it currently has. Answers 200 for a channel that is not active too, with `isActive: false`, so this does not tell you whether a channel has ever existed. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_get_channels_by_channel_id_messagesREADRead a channel's message history via GET https://rest.ably.io/channels/{channel_id}/messages. Read a channel's stored message history, newest first by default. `start` and `end` bound the window (milliseconds since the Unix epoch), `direction` is `backwards` or `forwards` and `limit` caps the page (100 by default). HISTORY ONLY EXISTS WHERE PERSISTENCE IS ON: message storage is a namespace setting (`persisted` on the channel rule), so a channel outside a persisted namespace answers `[]` here even immediately after a successful publish, and an empty reply is not evidence that nothing was published. `ably_control_get_apps_by_app_id_namespaces` is where that setting is visible. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_get_channels_by_channel_id_presenceREADRead who is present on a channel via GET https://rest.ably.io/channels/{channel_id}/presence. Read who is currently present on a channel -- the client ids and connection ids of the members, with whatever presence data each entered with. `clientId` and `connectionId` filter it and `limit` caps the page. This is a point-in-time read of a live set: members come and go with their realtime connections, so two calls seconds apart legitimately differ. Measured 2026-09-18: this route is granted by the key's `subscribe` capability, NOT by `presence` -- `presence` is what a realtime client needs to ENTER presence, which this REST integration never does. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_get_channels_by_channel_id_presence_historyREADRead a channel's presence history via GET https://rest.ably.io/channels/{channel_id}/presence/history. Read a channel's presence HISTORY -- the enter, update and leave events over a time window, rather than the current members. `start`, `end`, `direction` and `limit` shape it exactly as message history does, and the same persistence rule applies: this is stored data, so a channel whose namespace does not persist answers `[]`. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_get_push_channelsREADList channels with push subscribers via GET https://rest.ably.io/push/channels. List the channels that have at least one push-subscribed device, as a paginated list of channel names. This is the inverse of the subscriptions list: it answers 'which channels are pushing to anyone', where the other answers 'who is subscribed to this channel'. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_get_push_channelsubscriptionsREADList push channel subscriptions via GET https://rest.ably.io/push/channelSubscriptions. List push notification subscriptions -- which devices, or which client ids, receive push for which channels. AT LEAST ONE FILTER IS REQUIRED by Ably itself: measured 2026-09-18, a call with none answers 400 `expected parameter 'deviceId', 'clientId', 'deviceClientId', and/or 'channel'`, which Ably's own contract does not say. Pass `channel` to see who is subscribed to a channel, or `deviceId`/`clientId` to see what one device or identity receives. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_get_push_deviceregistrationsREADList registered push devices via GET https://rest.ably.io/push/deviceRegistrations. List the devices registered with this application for push notifications, each with its device id, platform, form factor, client id and push recipient details. `deviceId` and `clientId` filter it and `limit` caps the page. An app that has never registered a device answers `[]` (measured 2026-09-18). PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_get_push_deviceregistrations_by_device_idREADRead a push device registration via GET https://rest.ably.io/push/deviceRegistrations/{device_id}. Read one push device registration in full: its platform, form factor, client id, metadata and push recipient. A device id that is not registered answers 404 `device with ID ... not found` (measured 2026-09-18), which is a real absence rather than a routing failure. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_get_statsREADRead app usage statistics via GET https://rest.ably.io/stats. Read this application's aggregated usage statistics: messages, connections, channels and API requests, summed across all its channels. `start` and `end` are milliseconds since the Unix epoch, `unit` is the aggregation interval (`minute`, `hour`, `day`, `month`), `direction` orders `backwards` (the default) or `forwards`, and `limit` caps the page. Stats lag live traffic by a few seconds. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_patch_push_deviceregistrations_by_device_idWRITEUpdate a push device registration via PATCH https://rest.ably.io/push/deviceRegistrations/{device_id}. Change specific fields of a push device registration, leaving the rest alone. Only `clientId`, `metadata` and `push.recipient` are mutable. Replacing `push.recipient` is how a device's push token is rotated -- get it wrong and that device silently stops receiving notifications, because a bad token is a delivery failure rather than an API error. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_post_channels_by_channel_id_messagesWRITEPublish a message to a channel via POST https://rest.ably.io/channels/{channel_id}/messages. Publish a message to a channel. `name` is the message's event name and `data` its payload; `clientId` attributes it to a client identity, `extras` carries per-message options (including a `push` object that turns the publish into a push notification to that channel's subscribers). A message is delivered to whoever is attached at the time and is only retrievable afterwards if the channel's namespace persists it. THIS IS A BROADCAST: every client subscribed to that channel receives it, and there is no unsend. Measured 2026-09-18: a successful publish answers 201 with the channel and a message id. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_post_push_channelsubscriptionsWRITESubscribe a push device to a channel via POST https://rest.ably.io/push/channelSubscriptions. Subscribe a device -- or every device belonging to a client id -- to receive push notifications for messages published to a channel. Pass `channel` plus exactly one of `deviceId` or `clientId`. PUSH MUST BE ENABLED ON THAT CHANNEL'S NAMESPACE FIRST: measured 2026-09-18, this answers `401 push not enabled for this channel` on a namespace without it, even for a key with full capabilities, so a 401 here is a CONFIGURATION answer and not a credential one. `ably_control_post_apps_by_app_id_namespaces` (Control plane, a separate connection) is what turns it on. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_post_push_deviceregistrationsWRITERegister a push device via POST https://rest.ably.io/push/deviceRegistrations. Register a device for push notifications. `id` names the device, `platform` (`android`, `ios`, `browser`) and `formFactor` (`phone`, `tablet`, `desktop`, `watch`, …) describe it, `clientId` ties it to a client identity, and `push.recipient` carries the transport details the push service needs -- `transportType` plus, for FCM, a `registrationToken`, or for APNs a `deviceToken`. NORMALLY AN ABLY SDK ON THE DEVICE DOES THIS: registering a device server-side is for migrating an existing push estate or for fixing one up. The reply echoes the stored registration, including an update token the device would use to maintain itself. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_post_push_publishWRITEPublish a push notification to devices via POST https://rest.ably.io/push/publish. Send a push notification straight to a device or a set of devices, without publishing anything to a channel. `recipient` names them -- by `deviceId`, by `clientId`, or by a raw transport recipient -- and `notification` carries the title, body and the rest, with `data` for a silent payload. THIS REACHES PEOPLE'S DEVICES: a notification cannot be recalled, and addressing by `clientId` fans out to every device that identity has registered. Measured 2026-09-18: answers 204 whether or not the underlying push service ultimately delivers, so a 204 is Ably accepting the request rather than proof of delivery. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
ably_platform_put_push_deviceregistrations_by_device_idWRITEReplace a push device registration via PUT https://rest.ably.io/push/deviceRegistrations/{device_id}. REPLACE a push device registration entirely. Ably upserts on this route: whatever the registration held is replaced by what you send, so read it first and send the whole object rather than the part you meant to change. Only `clientId`, `metadata` and `push.recipient` are mutable; the device id, platform and form factor are fixed at registration. Use the PATCH tool to change one field. PLANE: Ably Pub/Sub REST API (https://rest.ably.io). This tool needs an Ably APP API KEY -- the credential the 'App API key' connection method collects -- and an account access token will not work on it. If this connection was made with a Control token, Agentic Fabriq refuses the call by name rather than forwarding it.
Often connected alongside
Put Ably behind one governed endpoint.
Same permissions, same audit trail, whatever else you connect next.