SEND A PUSH IN
ONE POST.

Request

GET /link?id=ABC12345&token=XYZ789TOKEN123

Use this for integration tests or setup flows.

cURL

curl "https://push.getnotifyapp.com/link?id=ABC12345&token=XYZ789TOKEN123"

Responses

{
  "success": true,
  "type": "device",
  "id": "ABC12345",
  "name": "Apollo",
  "notification_url": "https://push.getnotifyapp.com/notify/ABC12345",
  "last_active": "2024-12-28T10:30:00Z",
  "platform": "iOS",
  "os_version": "17.0",
  "app_version": "6.08.11",
  "message": "Device credentials validated successfully"
}

{
  "success": true,
  "type": "group",
  "id": "GRP56789",
  "name": "Family Notifications",
  "notification_url": "https://push.getnotifyapp.com/notify-group/GRP56789",
  "last_active": "2024-12-28T10:30:00Z",
  "member_count": 3,
  "created_at": "2024-12-01T08:00:00Z",
  "message": "Group credentials validated successfully"
}

name: for a device this is the name its owner gave it, or the one its client supplied when the OS withholds the real one (iPhone (iOS 27.0), Chrome on macOS). It is always a non-empty string, so you can display it directly. Fields are returned flat, not nested under device or group.

Error: 404 invalid id/token pair, 429 rate limit exceeded (5 calls/minute)

Request Examples

Basic notification (GET):

GET /notify/ABC12345?token=XYZ789TOKEN123&body=Hello%20World

Enhanced notification with all features (GET):

GET /notify/ABC12345?token=TOKEN&body=Server%20CPU%20at%2095%25&title=Alert&groupType=monitoring&iconUrl=https%3A%2F%2Fexample.com%2Ficon.png

cURL Examples

Basic notification:

curl "https://push.getnotifyapp.com/notify/ABC12345?token=XYZ789TOKEN123&body=Hello%20World"

Enhanced with custom title and icon:

curl "https://push.getnotifyapp.com/notify/ABC12345?token=TOKEN&body=Server%20down&title=Critical%20Alert&iconUrl=https://example.com/alert.png&groupType=server-alerts"

Using POST with threading:

curl -X POST "https://push.getnotifyapp.com/notify/ABC12345?token=TOKEN&body=Build%20passed&title=CI/CD&groupType=github-actions"

Responses

{
  "success": true,
  "deviceId": "ABC12345",
  "message": "Notification sent successfully",
  "apnsId": "12345678-1234-1234-1234-123456789012"
}

Errors: 403 invalid device token, 404 device not found

Request Examples

Basic group notification (GET):

GET /notify-group/GRP56789?token=GROUP_TOKEN&body=Hello%20team!

Enhanced notification with all features (GET):

GET /notify-group/GRP56789?token=TOKEN&body=Deploy%20complete&title=DevOps&groupType=deployments&iconUrl=https%3A%2F%2Fexample.com%2Fcheck.png

cURL Examples

Basic group notification:

curl "https://push.getnotifyapp.com/notify-group/GRP56789?token=GROUP_TOKEN&body=Hello%20team!"

Enhanced with custom title and icon:

curl "https://push.getnotifyapp.com/notify-group/GRP56789?token=TOKEN&body=Deployment%20successful&title=Production&iconUrl=https://example.com/success.png&groupType=prod-deploys"

Using POST with threading:

curl -X POST "https://push.getnotifyapp.com/notify-group/GRP56789?token=TOKEN&body=All%20tests%20passed&title=CI/CD&groupType=test-results"

Responses

{
  "success": true,
  "groupId": "GRP56789",
  "message": "Notification sent to 3 devices"
}

Errors: 403 invalid group token, 404 group not found

cURL

curl -fsS --retry 3 "https://push.getnotifyapp.com/ping/CHK7Q2ZK/aB3dE5fG7hJ9kL2" > /dev/null

Crontab heartbeat

# Ping every 30 minutes; alert if two in a row are missed
*/30 * * * * curl -fsS --retry 3 "https://push.getnotifyapp.com/ping/CHK7Q2ZK/aB3dE5fG7hJ9kL2" > /dev/null

Put the curl at the end of a job so a crashed job never pings, or run it on its own schedule as a machine heartbeat.

Responses

200 OK

Errors: 404 unknown beacon or wrong token (identical responses, nothing to probe). There is no failure-signal endpoint: down detection is purely timed, so to test an alert just stop pinging.

Lifecycle

Waiting (created, first ping arms the schedule) → Up → Down (no ping for period + grace, checked every minute) → Up on the next ping. Pausing in the app silences alerts; pings still count so resuming re-arms cleanly.

cURL: start, update, end

# Start: returns { "activityId": "LA7Q2ZKM" } - keep it
curl -X POST "https://push.getnotifyapp.com/live-activity/ABC12345?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Laundry","symbol":"washer.fill","tint":"#7C3AED","progress":0,"endsIn":2700}'

# Update: the bar moves in place
curl -X POST "https://push.getnotifyapp.com/live-activity/LA7Q2ZKM?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"progress":94}'

# End: without this a dead tile can linger for hours
curl -X DELETE "https://push.getnotifyapp.com/live-activity/LA7Q2ZKM?token=YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"progress":100,"status":"done"}'

Responses

Every success is 200 with JSON (a start called with &format=text answers with the bare id instead). The start response, with the id to keep:

{
  "success": true,
  "activityId": "LA7Q2ZKM",
  "expiresAt": "2026-08-10T23:24:00.000Z"
}

# Update
{ "success": true, "activityId": "LA7Q2ZKM" }

# End. Idempotent: ending an already-finished tile still succeeds,
# with "state" reporting how it actually finished ("ended"/"dismissed")
{ "success": true, "activityId": "LA7Q2ZKM", "state": "ended" }

# End on the device URL with no live tile: still success, never an error
{ "success": true, "message": "No live activity to end" }

# GET one tile (works for a day after it finishes; endReason says why:
# "script", "dismissed", "never-started", "overdue", "abandoned")
{ "activityId": "LA7Q2ZKM", "state": "active", "endReason": null,
  "content": { "title": "Laundry", "progress": 80, "endsAt": 1786456988 },
  "endsAt": "2026-08-11T13:56:28.000Z", "startedAt": "...",
  "updatedAt": "...", "endedAt": null, "expiresAt": "..." }

# GET on the device id: your live tiles (empty array when none)
{ "activities": [ { "activityId": "LA7Q2ZKM", "state": "active", ... } ] }

Errors: every error is JSON with error and a human-readable message written to be shown. 403 invalid token or unknown id (identical responses, nothing to probe), 409 the device cannot show tiles yet and the message says why; the device-URL ambiguity 409 (several tiles live, no new=1) also carries an activityIds array so a script can pick one, 410 the tile was dismissed or ended (the message names the reason; start a new one), 400 validation with the failing field named (a malformed JSON body gets the same treatment), 429 Apple is silently ignoring starts for this device: the message says how long to wait, machine-readable in retryAfterSeconds and a Retry-After header (openingTheAppMayHelp says whether opening the Notify app can shortcut it; when false, only the wait will), 502 the start failed, and deliveryState says how: "not-delivered" means no tile exists and starting again cannot duplicate one (retry only if retryAfterSeconds is present, and wait that long; without it the same request will fail the same way), while "unknown" means Apple never answered, a tile may be appearing, and the returned activityId should be polled rather than retried with new=1, 503 Live Activities temporarily disabled server-side (ending and status always keep working).

Good to know

A tile lives at most 8 hours (Apple's limit; the start response echoes it as expiresAt). Longer job? Start a fresh tile when the old one ends. If the user swipes the tile away, that is final: updates to its id return 410, and the device address answers the same 410 while the dismissed job would still have been running, so a looping script cannot respawn a swiped tile by accident (&new=1 starts a fresh tile deliberately, and after the job's window the device URL starts fresh on its own). Because the device address upserts, a retried call can never duplicate a tile. GET /live-activity/{activityId}?token=... reports status and, for finished tiles, why they ended; a bare GET /live-activity/{deviceId}?token=... lists your live tiles. The app records one History entry when a tile appears; the update stream stays out of history by design, so progress noise never buries real notifications. One more Apple quirk the server absorbs for you: updating or reinstalling the app rotates the device's start credential, and starts sent to the old one are accepted by Apple but never appear. The server notices (a start with no tile after 15 minutes reports never-started), backs off with an honest 429 instead of burning the device's spawn budget, and re-sends a pending start automatically the next time the app opens and reports a changed credential. If the credential comes back unchanged nothing is re-sent, deliberately: a start push stays deliverable for the same 15 minutes the row is re-drivable in, so re-sending on a hunch could put a second tile on the Lock Screen that no id addresses.

App configuration XML

<dict>
  <key>groupID</key>
  <string>GRPAB12C</string>
  <key>groupToken</key>
  <string>Ab3Df6Gh9Jk2Mn5</string>
</dict>

Per-MDM setup

Jamf Pro: Devices > the managed Notify! app > App Configuration > paste the dict (or add the two keys).

Microsoft Intune: Apps > App configuration policies > Add > Managed devices > select Notify! > add groupID and groupToken in the configuration designer (or paste the XML).

Workspace ONE: Apps & Books > edit Notify! > Assignment > Application Configuration > add the two keys.

App bundle ID: com.pingie.Notify.Notify-for-Change-Detection

Verify and troubleshoot

Success looks like: on the next app launch the group appears in Devices > Device Groups with the enterprise badge, without the user doing anything. The join retries automatically on every launch until it succeeds, so a temporary network failure heals itself.

To see exactly what happened, connect the device to a Mac and open Console.app, then filter on subsystem com.pingie.Notify category MDM:

No managed app configuration present: the configuration never reached the app. This is a deployment problem (requirement 1 or 2 above), not a values problem.

Managed app configuration is malformed: the config arrived but a value failed validation; the log says which key. Re-copy the ID and token from the app.

attempting enterprise auto-join: config is good; any remaining failure is network/server side and will retry next launch.