Transactional sends & Live Activities

Transactional lane

POST /v1/apps/:appId/notifications publishes straight to a dedicated high-priority queue. Transactional sends:

• are never queued behind campaign fan-outs (a 100k blast cannot delay an OTP — this is tested, not aspirational);
• are exempt from frequency caps and quiet hours;
• cost nothing extra — pricing is per active user, not per message.

curl -X POST https://api.../v1/apps/$APP_ID/notifications \
  -H "Authorization: Bearer $API_KEY" -H "Content-Type: application/json" \
  -d '{"subscriberId": "...", "title": "Your code", "body": "123456"}'

iOS Live Activities

Drive lock-screen / Dynamic Island widgets from your backend. Updates also ride the transactional lane — stale live data is worthless.

1. App side — start the activity and attach it to WingBlaze; the SDK registers the push token and keeps it fresh through rotation:

let activity = try Activity.request(attributes: attrs,
    content: .init(state: initial, staleDate: nil), pushType: .token)
WingBlaze.attachLiveActivity(activity) { serverId in
    // send serverId to your backend
}

2. Backend side — update and end by that id:

POST /v1/apps/:appId/live-activities/:id/update
{ "contentState": { "eta": "3 min" }, "alert": { "title": "Almost there", "body": "3 min away" } }

POST /v1/apps/:appId/live-activities/:id/end
{ "contentState": { "eta": "arrived" } }

Content state is limited to 4KB (APNs). Dead activity tokens and end events close the registry row automatically. Requires your app's Live Activity widget and push capability from your Apple developer setup.