PocketAlert
MessagingSend 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.
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 or 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 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
With FlowRunner
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 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 Capabilities
21 actionsMessages
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 triggersEvent 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.
Start building with PocketAlert
$100 in credits. No card required. Connect in minutes.