Pushinator

Send push notifications to iOS and Android devices through a Pushinator account, delivering to channel subscribers. Agents reach a subscribed audience without building a mobile backend.

3 actions API key available

Pushinator website ↗ Platform Documentation ↗ Capability data verified 2026-08-03

A monitoring flow confirms a production incident is real and not a flapping check

Agent resolves the right channel with List Channels, matching the environment the incident belongs to

Agent calls Send Notification to that channel with acknowledgment required, starting the retry ladder

Agent posts the same incident summary into the team channel so the record exists somewhere searchable

If the retry ladder runs out without an acknowledgment, the agent asks the incident owner whether to widen to a second channel or wake the escalation contact directly

What This Integration Enables

Pushinator has three actions. That is not a gap, it is the argument. Send a notification to a channel, create a channel, list channels. Everything else a notification platform usually sells you, templating, segmentation, analytics, campaign management, is deliberately absent, because this connector is not trying to be the system of record. It is trying to be the last hop: the step at the end of someone else's flow that gets a message onto a phone.

What it does have that most push connectors do not is a genuine acknowledgment loop. A notification can require acknowledgment, and an unacknowledged one is redelivered up to five times with exponential backoff at one, two, four, eight and sixteen minutes, with retries stopping the moment a subscriber confirms. That turns "sent" into a state with an ending, which is the property an escalation policy actually needs. Acknowledgment is available on paid plans and is treated as false on the Free plan, so a flow that depends on it should confirm the plan before it depends on it. Around that, agents create a channel per project or environment so subscribers opt into the streams that concern them, and devices subscribe by scanning a QR code in the mobile app.

Without FlowRunner

Sent is treated as received An alert leaves the system and everyone assumes a person saw it

One channel for everything Staging noise and production incidents reach the same subscribers at the same volume

Silence is ambiguous Nobody knows whether the alert was missed, ignored, or never delivered

With FlowRunner

Acknowledgment is the outcome A critical notification retries on a fixed ladder until a subscriber confirms receipt

A channel per environment Subscribers opt in to the streams that concern them, and staging noise stays out of production channels

Silence becomes a decision An unacknowledged alert escalates to a named person rather than expiring quietly

Use Case Scenarios

The escalation that ends in an answer

An uptime check fails three times in a row on a production endpoint. The agent confirms the failure is sustained rather than a single blip, resolves the production channel with List Channels, and sends an acknowledgment required notification. The retry ladder runs. If someone acknowledges at minute two, the flow records who and closes the loop. If the full ladder passes with no acknowledgment, the flow has learned something worth acting on, which is that the primary on-call is unreachable, and that is a different problem from the outage.

A channel per environment, created by the flow that needs it

A new service is provisioned. As part of the provisioning flow, the agent calls Create Channel with a name matching the environment and a description saying who should subscribe, then posts the channel name into the engineering channel in Slack so the team knows what to scan. Alerts for the new service route to a channel that existed before the first incident, rather than being bolted onto whatever channel was closest.

Telling people something finished

A long overnight data load completes. Nobody needs to be woken for it, so the agent sends a plain notification without acknowledgment to the data operations channel with the row counts and the run duration, and writes the same summary to the run record in Google Sheets. Reserving acknowledgment for the cases that genuinely need a human response is what keeps the acknowledgment meaningful when it is used.

Human-in-Loop Highlight

Here is the honest limitation, and it is the reason this connector needs a person in the loop rather than a threshold. List Channels returns a channel's UUID, name and description. It does not return its subscribers. There is no roster action on this connector, because subscription happens on the device: a person scans a QR code in the Pushinator app and from that moment they are on the channel, and nothing in the API will tell a flow that they are there. So when an agent fires an acknowledgment required notification at the production channel at three in the morning, it is starting a thirty one minute retry ladder against an unknown number of phones belonging to unknown people, and it cannot check first. That is not a defect to engineer around. It is a fact to design the human-in-the-loop step onto. The agent handles the alert itself autonomously, and when the ladder expires without an acknowledgment, it stops: "The production incident notification has gone unacknowledged through all five retries over 31 minutes. I cannot see who subscribes to this channel. Widen to the platform channel, or call the escalation contact?" A person answers, because the next move is about people and the connector does not model people.

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

3 actions

Notifications

Send Notification Sends a push notification to every device subscribed to a Pushinator channel, delivered immediately. When acknowledgment is required, an unacknowledged notification is redelivered up to five times with exponential backoff at one, two, four, eight and sixteen minutes, and retries stop once a subscriber acknowledges. Acknowledgment is available on paid plans and treated as false on the Free plan.

Channels

Create Channel Creates a new notification channel and returns its properties including the UUID. Devices subscribe to channels to receive what is sent to them, so this is how a flow provisions an alert stream for a new project or environment ahead of the first incident.
List Channels Retrieves all notification channels on the account, each with UUID, name and description. Used to resolve the correct channel by name before sending. It returns channels, not subscribers, so a flow can confirm where it is sending but not who will hear it.

Frequently Asked Questions

What can FlowRunner do with Pushinator?

FlowRunner agents can run Send Notification, Create Channel, and List Channels in Pushinator.

Does connecting Pushinator to FlowRunner require OAuth?

No. Pushinator connects to FlowRunner with an API key, no OAuth flow required.

Can Pushinator trigger a FlowRunner workflow automatically?

Pushinator doesn't currently expose triggers in FlowRunner. It connects as an action step inside workflows started by another trigger.

Start building with Pushinator

$100 in credits. No card required. Connect in minutes.

Start Building Free Talk to us