Skip to main content
Push is the tap on the user’s shoulder: it brings them back to your site or app without SMS or email, ideal for users who already accepted notifications.

​
What is Push on Notifique?

It’s the channel to alert in the browser or app for users who granted permission. You organize Push App, devices, and sends in the same workspace; your integration stores device IDs (and can link them to a CRM contact) and sends when needed. You can:
  • Create Push Apps with Web VAPID (auto-generated), FCM (Android) and APNs (iOS)
  • Register devices on web (script) or mobile (FCM/APNs token), optionally with contactId
  • Send to device IDs or toContacts (all devices for a contact)
  • Rich Web Push: image, badge, tag, actions, requireInteraction, and more
  • Schedule and cancel future sends
  • Track delivery and clicks via API or webhook
  • BYOK: Firebase/APNs under Integrations (same pattern as Resend/SES for email)
Think of a reminder on the phone screen: short, direct, for people who already said “yes” to notifications.
Unlike WhatsApp, push does not use a channel instance. You only need a Push App, registered devices, and an API Key with the right scopes.
Custom sound works on mobile (APNs/FCM). On modern browsers, custom Web Push sound is limited or unavailable.

​
When to use it?

Works great for abandoned cart, fast updates, and bringing users back. If they never opened the site or denied permission, use email or SMS. Long HTML content → email.

​
How it works in practice

  1. Create a Push App, Web VAPID is generated automatically (or configure your own keys later)
  2. Register devices when the browser delivers the subscription to your backend, save the device ID
  3. Send with to (array of device IDs), title and/or body
  4. The platform queues, sends, and updates status; your backend gets alerts if you configured webhooks
Each API Key belongs to one workspace. On v1 do not send x-workspace-id.

​
Send lifecycle

After POST, the notification moves through QUEUED or SCHEDULED, then SENT, DELIVERED, or CLICKED as the device reports. Failures become FAILED; cancelled schedules become CANCELLED. Delivery and clicks can be reported by the service worker on the client. Webhooks notify your backend (push.delivered, push.clicked).

​
What you can do

  • Send to 1 to 100 device IDs per call (1 credit per notification)
  • Schedule with schedule.sendAt
  • Query history or one send by id
  • Cancel scheduled sends while status is SCHEDULED
  • Idempotency with Idempotency-Key header
  • Priority in options.priority: high, normal, low
  • Restrict by app with pushAppIds on the key, outside the list → 403 (PUSH_APP_NOT_ALLOWED)
Field and error details: API reference on the Push tab (sidebar).

​
After your first send

  • Track via webhooks (push.sent, push.delivered, push.clicked, push.failed)
  • Remove devices with invalid subscriptions when you receive push.failed
  • Test in Sandbox with sk_test_... before production

​
Next steps