--- title: "PocketAlert Integration" description: "Send push notifications to iOS and Android devices through a PocketAlert account, reaching all devices or a single one. Agents deliver time-sensitive alerts straight to the phone." url: https://flowrunner.ai/integrations/pocketalert date_modified: 2026-08-07T17:20:23-07:00 --- # PocketAlert [Messaging](https://flowrunner.ai/integrations/category/communication-messaging) Send push notifications to iOS and Android devices through a PocketAlert account, reaching all devices or a single one. Agents deliver time-sensitive alerts straight to the phone. [Verified](https://flowrunner.ai/integrations/verified "What does verified mean?") · 2 triggers · 21 actions · API key · available [PocketAlert website](https://pocketalert.app/) · [Platform Documentation](https://pocketalert.app) · Capability data verified 2026-08-12 1. A nightly close job fails and the flow that watches it has nowhere useful to put the failure 2. Agent resolves which PocketAlert application the alert belongs to with Get Applications 3. Agent pulls the failing step, the error text and a link to the run 4. Agent calls Send Message with the error title, the detail and the application assignment so it groups correctly on the phone 5. Agent watches Get Messages for the read status to confirm the alert was actually opened rather than merely delivered 6. If it stays unread past the escalation window, the agent asks the operations lead in Slack whether to page the secondary or hold until morning ## What This Integration Enables PocketAlert is a small alerting stack pretending to be a push API, and the second half is the interesting half. The sending side is what you expect: an agent calls Send Message with a title and body, targets all registered devices or a single one, and can attach an image on paid plans. The rest of the connector is plumbing an agent can build and take apart on its own. Applications categorize messages so the phone shows Monitoring separately from Sales. Devices are enumerable and renameable. And inbound webhooks are provisionable from a flow: Create Webhook returns a receive URL, and any external service that can POST JSON to it gets its payload rendered into a push through a message template using GJSON path placeholders. That last piece changes the design. It means an agent does not have to be in the delivery path for every alert. It can stand up a receive URL, hand it to [Sentry](https://flowrunner.ai/integrations/sentry) or [GitHub](https://flowrunner.ai/integrations/github) or an uptime checker, and let those tools push directly to the team's phones while the flow handles only the events that need judgment. FlowRunner's [connectors](https://flowrunner.ai/concepts/connectors) are usually the thing carrying the message. Here the connector can also be the thing that builds the channel and then gets out of the way. ### Without FlowRunner **Alerts arrive in a channel nobody watches at night**: A failure lands in a chat room and waits for the next person to scroll back **Every alert looks the same**: Monitoring, sales and billing notifications share one undifferentiated stream on the phone **Third party tools need their own plumbing**: Getting a build failure to a phone means writing a small service to bridge it ### With FlowRunner **The failure reaches a pocket**: The alert arrives as a push on the registered devices, not only in a log **Grouped by application**: Alerts are assigned to applications so monitoring, CI and sales are distinguishable at a glance **External tools post directly**: An inbound webhook renders another tool's JSON into a push without a bridge service ## Use Case Scenarios ### A failure that reaches someone, and proof that it did A scheduled reconciliation job fails. The agent resolves the Monitoring application, calls Send Message with the failing step and the error text, then polls Get Messages to watch the read status. Delivery is not the outcome anyone cares about. Being read is. If the message is still unread after the escalation window, the flow does not send a second identical push. It escalates to a person in [Slack](https://flowrunner.ai/integrations/slack) with the age of the unread alert attached, which is a different signal from the alert itself. ### Wiring an external tool straight to the team's phones A new service goes live and needs alerting. The agent calls Create Application to make a category for it, then Create Webhook with a message template that pulls the fields worth seeing, for example the repository name and the commit message from a push payload. Create Webhook returns the receive URL, and the agent registers that URL in the external tool. From then on, that tool's alerts arrive as grouped notifications without the flow touching them at all. The agent built the pipe rather than being the pipe. ### Keeping the device roster true to the team On New Device fires when someone registers a phone through the PocketAlert mobile app. The agent looks the person up in the HR system, renames the device with Update Device so it is identifiable rather than a serial number, and posts a note to the team channel. When someone leaves, the offboarding flow calls Delete Device, and because a deleted device must be re-registered through the mobile app to receive anything again, that step is deliberate and logged rather than a background sweep. ## Human-in-Loop Highlight Delete Application is the operation on this connector that quietly breaks the thing you built. It permanently deletes an application together with all of its messages and all of its webhooks. The messages are a retention question and most teams will shrug at losing them. The webhooks are the problem: those are inbound receive URLs that external systems are still posting to. Delete the Monitoring application during a tidy up and every uptime checker, error tracker and CI job still fires happily into a URL that no longer produces a notification. Nothing errors. Nobody is told. The next real incident simply does not reach anyone's phone, and the failure is discovered by a customer. So when a cleanup flow is about to remove an application, the agent first calls Get Webhooks, lists every receive URL attached to it and the template each one renders, and stops: "Deleting the Monitoring application will also delete 3 inbound webhooks. These receive URLs are live and external services are posting to them. Confirm deletion, or reassign the webhooks first?" A person answers. The reversible half, disabling a webhook through Update Webhook, needs no gate at all, because it can be switched back on. Agent processes routinely Detects exception requiring judgment Clear match Continues automatically Ambiguous Routes to human via preferred channel Human decides Agent resumes with decision ## Agent Capabilities 21 actions ### Messages 7 - **Send Message** Sends a push notification to your PocketAlert devices with a title and body. Optionally assigns the message to an application for categorization or targets a single device, and delivers to all registered devices when no device is given. Returns the created message with its identifier. - **Send Message With Attachment** Sends a push notification with an image fetched from a URL and uploaded to PocketAlert. Supports .png, .jpg, .jpeg and .gif, and is available on paid plans. Used when the alert is a chart, a screenshot or a scan that says more than the text would. - **Get Messages** Retrieves the messages in the account sorted by creation time, each with title, body, application and device names, read status and timestamp. Used to check whether an alert was actually opened, which is a different question from whether it was delivered. - **Get Message** Retrieves a single message by identifier with its full detail. Used to follow up on a specific alert in an audit or escalation flow. - **Update Message** Updates an existing message's title, body, application or device assignment, or marks it read or unread. Title and body are required on every update. - **Delete Message** Permanently deletes a message by identifier. This cannot be undone, so it belongs to a retention policy rather than an ad hoc cleanup. - **Get Message Statistics** Retrieves message counts grouped by date, returning daily entries with the number of messages sent. Used to spot the week your alert volume doubled, which is usually the week people started ignoring it. ### Applications 5 - **Get Applications** Retrieves all applications in the account with identifier, name, active status and creation timestamp. Used to resolve the right category before sending. - **Get Application** Retrieves a single application by identifier. Used to confirm a category exists before assigning messages to it. - **Create Application** Creates a new application to organize and categorize messages, with a name and optional hex color. Used to give a new service its own lane on the phone rather than adding to the general stream. - **Update Application** Renames an existing application. Used when a service or team is renamed and the alert grouping should follow. - **Delete Application** Permanently deletes an application together with all of its associated messages and webhooks. This cannot be undone, and it silently disables every inbound receive URL attached to the application. ### Devices 4 - **Get Devices** Retrieves all devices registered to the account through the PocketAlert mobile app, each with identifier, name, serial number, active status and registration timestamp. Used to see who is actually reachable before relying on a broadcast. - **Get Device** Retrieves a single device by identifier. Used to confirm a target device before sending to it specifically. - **Update Device** Renames a device. Used during onboarding so an on-call roster reads as names rather than serial numbers. - **Delete Device** Removes a device from the account. This cannot be undone and the device must be re-registered through the mobile app to receive notifications again, which makes it an offboarding step rather than a maintenance one. ### Inbound Webhooks 5 - **Get Webhooks** Retrieves all inbound webhooks in the account, each with identifier, name, URL slug, message template and active status. Used to audit which external systems can push directly to the team's devices. - **Get Webhook** Retrieves a single inbound webhook with its template and status. Used before changing a template to see what the current rendering produces. - **Create Webhook** Creates an inbound webhook that turns JSON posted by an external service into a push notification, using a message template with GJSON path placeholders to pull fields out of the payload. Returns the webhook with its URL slug and the computed receive URL to register in the external tool. - **Update Webhook** Updates an inbound webhook's name, message template, application or device assignment, or enables and disables it. Only the supplied fields change, and disabling is the reversible way to silence a noisy source. - **Delete Webhook** Permanently deletes an inbound webhook. External services posting to its receive URL will no longer generate notifications, and they will not be told. ## Triggers 2 triggers ### Event Triggers 2 - **On New Message** Fires when a new message appears in the account, whether it came from the API, an inbound webhook, the browser extension or the dashboard. The first run records a baseline and emits nothing, then each newly seen message fires once. Used to react to alerts that external tools pushed in directly, so a flow can enrich or escalate something it did not send. - **On New Device** Fires when a new device is registered through the PocketAlert mobile app, de-duplicated by identifier, carrying the device name, serial number, active status and registration timestamp. Used to run onboarding: rename the device, record who it belongs to, and confirm the on-call roster is reachable. ## Frequently Asked Questions ### What can FlowRunner do with PocketAlert? FlowRunner agents can run Send Message, Send Message With Attachment, and Get Messages in PocketAlert, plus 18 more actions. ### Does connecting PocketAlert to FlowRunner require OAuth? No. PocketAlert connects to FlowRunner with an API key, no OAuth flow required. ### Can PocketAlert trigger a FlowRunner workflow automatically? Yes. PocketAlert supports 2 triggers that can start a FlowRunner workflow automatically. **Work at PocketAlert?** This integration exposes PocketAlert to AI agents on every FlowRunner plan, including through MCP, at no cost to you. [See what FlowRunner offers integration partners](https://flowrunner.ai/integrations/partners), including how to keep this page current. --- Markdown version of https://flowrunner.ai/integrations/pocketalert. Site index: https://flowrunner.ai/llms.txt