Do I need my own Apple and Google accounts?

Yes. You upload an APNs auth key and a Firebase service account, and honkio sends with them. honkio never sends under its own credentials for your app.

Is it end-to-end encrypted?

No. For a device that registered a key, Apple and Google cannot read the content, and a device can read only its own pushes. But honkio encrypts the content, so it sees it. It is confidentiality from Apple and Google, not end-to-end encryption.

Do I have to install an SDK?

You don't have to. Your app gets its token from Apple or Google as usual, and your backend registers it with the API, with the Node, Python or PHP SDK or plain HTTP. Optional Swift and Android packages put the token in the form honkio expects and, on a device that has registered its own key, decrypt its pushes; they never call honkio and hold no API key.

What if the phone is off?

Apple and Google hold an accepted push until it is delivered or expires. honkio cannot see that, so a push that was accepted does not fall back to a text.

Is anything stored outside Canada?

honkio stores push data in Canada. Pushes are processed by Apple and Google in the United States and other countries, and the API runs on US-hosted infrastructure.

Push notifications

Push notifications stored in Canada, with a text fallback

Send push to iOS and Android with your own Apple and Google credentials, encrypt the content when you choose to, and fall back to an SMS in the same call.

Create a free account Read the push quickstart

Built for transactional push

Messages your app sends to its own users, when something has happened.

Sign-in codes: A code to the phone the person is holding, and a text if the push cannot reach it.
Reminders: Appointments, deliveries and due dates, sent when they matter.
Receipts: Confirmation of an order or a payment, with your own data attached.
Alerts: Something needs attention now: a failed payment, a security notice, a status change.

What you get

One API from your backend to every device, with no mobile SDK required.

Your own credentials: You upload your APNs key and Firebase service account. honkio never sends under its own credentials for your app, and never returns yours.
One call, every device: Send to a user ID and every active device of that user gets the push. Tokens are retired when Apple or Google say they are invalid.
A text when push fails: Add a fallback and a text goes out when no device accepts the push, under every SMS rule: consent, opt-outs and sending limits.
Honest delivery status: Accepted by Apple or Google is reported as accepted, not as seen. honkio cannot see a phone that is off or has notifications disabled.
Test mode: Test keys send nothing and charge nothing, and magic tokens simulate each outcome.
Webhooks: Eight events for pushes, retired devices and invalid credentials, with IDs and status but never content.

bash

curl -X POST https://api.honkio.ca/v1/push \
  -H "Authorization: Bearer mk_test_YOUR_KEY" \
  -H "Idempotency-Key: login-code-1042-2026-11-03" \
  -H "Content-Type: application/json" \
  -d '{
    "app_id": "APP_ID",
    "to": { "user_id": "user_1042" },
    "title": "Your code",
    "body": "123456",
    "fallback": {
      "sms": { "to": "+14165550123", "from": "+14165550100", "body": "Your Acme code is 123456" }
    }
  }'

Content Apple and Google cannot read, for every device with a key

Each device makes its own key with the HonkIO Swift or Android package. A device without one gets plain content, unless you require encryption.

For a device that registered a key, Apple and Google receive a placeholder and an encrypted envelope, not your title and body.
The HonkIO Swift and Android packages make the key and decrypt the push, and the docs have a test vector for your own code.
honkio encrypts the content, so this is confidentiality from Apple and Google, not end-to-end encryption. Each device can read only its own pushes.
Badge, sound and thread ID stay in plain text on iOS. The collapse key stays in plain text on iOS and Android.

Read the encryption guide

Stored in Canada, sent through Apple and Google

honkio stores push credentials, device tokens, content and logs in Canada.

A push still goes through Apple's or Google's servers, in the United States and other countries, and honkio's API runs on US-hosted infrastructure. Stored in Canada does not mean processed only in Canada.

Title, body and data are deleted after 90 days by default.

Where push data goes

Pricing

Prices are in Canadian dollars, before tax.

Accepted push: $5.00 per 1,000After the first 2,500 each calendar month, which are free. Test pushes are free. A fallback text bills at the SMS price.

See all pricing

Docs

Everything from the first credential to the webhook.

Questions

Do I need my own Apple and Google accounts?: Yes. You upload an APNs auth key and a Firebase service account, and honkio sends with them. honkio never sends under its own credentials for your app.
Is it end-to-end encrypted?: No. For a device that registered a key, Apple and Google cannot read the content, and a device can read only its own pushes. But honkio encrypts the content, so it sees it. It is confidentiality from Apple and Google, not end-to-end encryption.
Do I have to install an SDK?: You don't have to. Your app gets its token from Apple or Google as usual, and your backend registers it with the API, with the Node, Python or PHP SDK or plain HTTP. Optional Swift and Android packages put the token in the form honkio expects and, on a device that has registered its own key, decrypt its pushes; they never call honkio and hold no API key.
What if the phone is off?: Apple and Google hold an accepted push until it is delivered or expires. honkio cannot see that, so a push that was accepted does not fall back to a text.
Is anything stored outside Canada?: honkio stores push data in Canada. Pushes are processed by Apple and Google in the United States and other countries, and the API runs on US-hosted infrastructure.

SMS API
Send and receive SMS with Canadian local and toll-free numbers, with CASL consent and STOP replies enforced in the API.
Email API
Send transactional email from your own domain and receive replies over the API, with CASL checks and data stored in Canada.
Verify
One-time codes by text message, to confirm that a Canadian phone number belongs to your user.
CASL for developers
What Canada’s anti-spam law asks of the code that sends texts and email: consent, identification, unsubscribes and records.

Try it in test mode first

Create a free account

Test keys work right after sign-up, with no card and no charges.