Skip to main content

​
Operator Push (Handoff Alerts)

When the support assistant escalates a chat to a person, KnoxCall pushes a notification to the operator’s phone. Pick one provider. Scope: Global defaults only — this is a platform operator feature. On a self-hosted deployment without the support assistant, leave it unconfigured.

​
1. Pick a provider

​
ntfy

The default. A public topic on ntfy.sh needs no credential at all — but anyone who guesses the topic name can read it, so use an unguessable name (knoxcall-support-7f3a9c…) or a self-hosted, auth-locked ntfy server.
  1. Choose the topic name and subscribe to it in the ntfy app.
  2. Self-hosted ntfy with auth: create an access token for a user that may publish to the topic.

​
Telegram

  1. Message @BotFather → /newbot → copy the bot token (123456789:ABC…).
  2. Send your new bot one message — the chat does not exist until you do.
  3. Read your chat id from https://api.telegram.org/bot<token>/getUpdates (the chat.id field).

​
Pushover

  1. Pushover → Create an Application/API Token → copy the application token.
  2. Your user key is on the Pushover dashboard.

​
2. Enter it in KnoxCall

Settings → Integrations → Global defaults → Operator push (handoff alerts) → Configure. Fill in the rows for your provider and leave the rest blank: Save credentials.

​
3. Verify

Trigger a hand-off in the assistant, or — for ntfy — publish to the topic yourself and confirm the phone buzzes.

​
Things that bite

  • Set Provider explicitly for Telegram and Pushover. With it blank, KnoxCall only infers ntfy (from a topic being present). A Telegram token with no provider sends nothing, silently.
  • Environment fallback. Every field also falls back to an OPERATOR_PUSH_* environment variable on a self-hosted host, so an empty row does not prove push is off.
  • Public ntfy topics are public. Treat the topic name as a secret.