Apple Push Notifications

Apple Push Notifications (APNs) delivers alerts to your own iOS, iPadOS, macOS, watchOS, and tvOS apps. Workflows send alert, background, VoIP, and Live Activity pushes to one device or many, signed with your .p8 key.

Verified 6 actions Custom auth available

Platform Documentation Capability data verified 2026-08-25

A carrier reports an exception on an order the customer is already tracking

Agent reads the order, the customer's device token, and the activity's own push token

Agent confirms the token was issued by the same build environment the connection is configured for

Update Live Activity rewrites the Lock Screen card with the new delivery window

Send Notification posts a visible alert carrying a Collapse ID, so it replaces the earlier undelivered update rather than stacking on it

An operator approves before the flow raises any alert to a level that overrides a silenced phone

What This Integration Enables

Apple Push Notifications is the one channel into a customer's pocket that you own outright. There is no intermediary deciding whether the message is promotional, no per message fee, and no third party sitting between your workflow and the device. FlowRunner agents use it to move an operational fact from wherever it happened into the app the customer already has open on their Lock Screen: a delivery window that moved, a job a technician accepted, a payment that cleared, an approval waiting in a queue.

What APNs does not give you is a receipt. A phone that is switched off, out of storage, or set to refuse notifications returns exactly the same acceptance as one that showed the alert, and there is no read receipt anywhere in the protocol. The only honest signal is the reverse one: Apple reporting that the app is no longer installed. This connector is built around that asymmetry, and it is why the result reports that Apple accepted the push rather than claiming it arrived. An agent that cannot measure what it sent is an agent that should be careful about what it is allowed to send unattended, which is where the human-in-the-loop gate below sits.

Without FlowRunner

Alerts stuck behind a release Reaching your own app's users means shipping code, so operational messages wait on a build

Notification stacking Every status change adds another alert, and the customer wakes to a column of stale ones

Dead tokens never cleaned Uninstalled apps stay in the database and every campaign sends to them again

With FlowRunner

Messages sent from the flow The workflow that knows the status is the workflow that delivers it, with no app release in between

One notification that updates A collapse identifier replaces the earlier undelivered alert, and a Live Activity changes in place

Token hygiene as a by-product A fan-out send separates the tokens Apple reports as permanently invalid, ready to delete

Use Case Scenarios

A delivery that updates itself on the Lock Screen

An order ships from Shopify and the fulfillment record lands from ShipStation. The customer's app started a Live Activity at dispatch and sent its push token to the backend, and the flow holds it against the order. As the carrier reports movement, the agent calls Update Live Activity to rewrite the card in place, so the customer sees one live delivery estimate rather than a queue of notifications. When the parcel is handed over, the agent sends a final update with a dismissal date and an end event, which is what makes the activity disappear instead of lingering on the Lock Screen looking stuck.
On-call escalation into your own operations app

A monitor in Datadog fires and the flow classifies it. Routine alerts post to the team channel in Slack and nowhere else. Anything crossing the on-call threshold goes to the engineer's device through Send Notification with a category the app registered, so the alert arrives with acknowledge and escalate buttons rather than as plain text. If the acknowledgement does not come back inside the window, the agent hands off to PagerDuty rather than pushing again, because a second identical push to the same token is the fastest way to get rate limited by Apple.
A campaign send that leaves the token list cleaner than it found it

Marketing approves a release announcement. The agent pulls the audience, chunks it, and calls Send To Many Devices, which does not stop at the first failure. Alongside the per token outcomes it returns the tokens Apple reports as permanently invalid, and that list goes straight back into the database as deletions. The campaign's most durable output is not the opens. It is that the next send is smaller and truer.

Human-in-Loop Highlight

Every operation here sends something that cannot be recalled and cannot be measured, so the gate is not on sending. It is on how loudly. Interruption Level on Send Notification, and a critical alert sound object built by hand through Send Raw Notification, are the settings that reach past a phone set to Do Not Disturb and ring anyway. Apple grants that capability by entitlement, and without the entitlement the notification is quietly delivered at normal priority rather than refused, so a flow cannot tell from the response whether it just overrode someone's evening or did nothing at all. The agent therefore composes the alert, resolves the audience, and stops: "Sending to 4,180 devices. The classifier rated this as a service outage and wants time-sensitive delivery, which bypasses Do Not Disturb and Focus. Send at normal priority, or approve the escalation?" The operator answers. What the agent is not permitted to decide on its own is when your app is allowed to override a customer's own decision to be left alone.

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

6 actions

Notifications

Send Notification Sends a visible push notification to one device. A success means Apple accepted the push, not that it arrived: there is no delivery receipt, and a device that is off or has notifications disabled looks identical to one that showed the alert. Badge accepts zero, which clears the badge rather than being dropped as an empty value, and Collapse ID replaces an earlier undelivered notification carrying the same identifier instead of stacking another one beside it, which is what a score, a queue count, or a delivery status wants.
Send Background Notification Wakes the app in the background with no visible notification. Apple treats these as best effort and throttles them hard: a device in Low Power Mode, or one whose owner rarely opens the app, may receive few or none, and no error says so. Never use a background push for anything that must happen. Priority is forced to the value Apple accepts for this push type, because it rejects a background push sent at alert priority.
Send VoIP Push Sends a PushKit VoIP notification, which wakes the app immediately to report an incoming call. iOS requires the app to report a call to CallKit the moment one of these arrives and terminates the app if it does not, so this is not a general high priority channel and misusing it gets the app killed. The topic suffix this push type needs is appended for you, and the payload ceiling is larger here than for a standard alert.
Send Raw Notification Sends a payload you build yourself, with any push type. This is the escape hatch for the shapes the named operations do not model and for whatever Apple adds next: a critical alert's sound object, filtering criteria, or a push type such as location or push to talk. The topic suffix for the chosen push type is still appended for you and the payload is still size checked before it leaves.
Send To Many Devices Sends the same notification to a list of device tokens and reports the outcome for each. It does not stop on the first failure, so a dead token in the middle of a list cannot abort the whole send, and it separates the dead tokens out: the ones Apple reports as permanently invalid come back in their own collection, which is the list to delete from your database. APNs publishes no bulk endpoint, so this is one request per token, and Apple rate limits repeated pushes to the same device.

Live Activities

Update Live Activity Pushes a state update to a Live Activity on the Lock Screen or Dynamic Island. The topic needs a live activity suffix, which this service appends for you, because Apple's failure without it is a bare topic error that explains nothing. The device token here is the activity's own push token rather than the app's, it comes from the Activity object inside the app, and it differs for every activity. A dismissal date sent with an end event is how an activity is cleared rather than left sitting on the Lock Screen.

Frequently Asked Questions

What can FlowRunner do with Apple Push Notifications?

FlowRunner agents can run Send Notification, Send Background Notification, and Update Live Activity in Apple Push Notifications, plus 3 more actions.

Does connecting Apple Push Notifications to FlowRunner require OAuth?

Apple Push Notifications uses a custom authentication method to connect to FlowRunner.

Can Apple Push Notifications trigger a FlowRunner workflow automatically?

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

Start building with Apple Push Notifications

Free plan, no card required. Connect in minutes.

Start Building Free Talk to us