User Guide

A comprehensive, step-by-step guide to every feature of WardenPoint. If you have a question — the answer is here.

How it works — 4 simple steps

🚀 Getting Started

📊 Dashboard

The dashboard is your main workspace. Here's what each section does:

👥 Recipients

Recipients are the people who receive your notifications. Each recipient must have a name and at least one contact method. The more contact methods you add, the more channels the system can use for delivery and escalation.

Adding recipients

Click 'Add Recipient' in the Recipients section. Fill in the name (required), and at least one of: Telegram username (e.g., @johndoe), phone number (international format, e.g., +380501234567), or email address. You can add all three — this gives the system the most flexibility for channel selection and escalation.

Contact types and what they unlock

Each contact type enables specific notification channels:

Recipient groups

Groups let you organize recipients (e.g., 'Backend team', 'Night shift', 'Management'). When you send a notification to a group, every member of that group receives it. You can also set notification rules at the group level — for example, all members of the 'Critical Alerts' group get voice calls by default.

CSV Import

To add many recipients at once, use CSV import. Go to Recipients → Import. Your CSV must have a header row with columns: name, phone, email, telegram_username. Only the 'name' column is required — others are optional. Example:

📡 Notification Channels

WardenPoint supports 9 notification channels across 7 providers. Each channel has different strengths: text channels are great for informational alerts, voice channels grab immediate attention for critical situations. Here's a detailed breakdown:

🔔 Priorities

Every notification has a priority level that determines how aggressively it is delivered and escalated. Choose the right priority for each situation:

⚡ Escalation

Escalation is the core feature that makes WardenPoint different from a simple notification sender. When a notification is sent, the system doesn't just fire-and-forget — it tracks whether the recipient acknowledged it, and takes action if they didn't.

What is escalation?

After sending a notification, the system waits for an acknowledgment (ACK) from the recipient. ACK can happen by: clicking an acknowledgment link in a Telegram message, clicking a link in an email, or simply answering a voice call. If no ACK is received within the configured timeout (e.g., 2–5 minutes), the system moves to the next escalation step: sends via a different channel, retries the same channel, or notifies a manager.

Escalation policies

You can create reusable escalation policies in Dashboard → Escalation Policies. A policy is a set of ordered rules: 'first send Telegram text, wait 3 min, then call via PBX, wait 2 min, then notify the manager'. Policies can be assigned to individual recipients or groups.

Available escalation actions

Acknowledgment (ACK)

ACK is how the system knows the recipient got the message. For Telegram text — clicking the acknowledgment link in the message. For Telegram voice/call — the message being delivered. For email — clicking the acknowledgment link. For voice calls — answering the call. Once ACK is received, the escalation chain stops immediately — no further steps are executed.

⚙️ Notification Settings

Notification settings let you fine-tune how each recipient (or group) receives alerts. You can configure these per priority level:

📤 Sending Notifications

There are two ways to send notifications: manually through the dashboard, or programmatically via the REST API.

Sending from the dashboard

Go to Dashboard → Notifications → Send Notification. Select a recipient (or group), type your message (up to 4,096 characters), choose a priority level, and optionally attach an audio file. Click Send. The notification will be processed immediately — you'll see the status update in real time on the Notifications page.

Sending via API

Use the REST API to send notifications from your monitoring tools, scripts, CI/CD pipelines, or any other system. All API endpoints are under /api/v1/ and require an API key for authentication. Here are the available methods:

🔌 API Integration

The WardenPoint REST API lets you integrate notifications into any system. All endpoints are versioned under /api/v1/ and return JSON responses.

Authentication

Every API request must include your API key in the X-API-Key header. You can create API keys in Dashboard → Settings → API Keys. Each key is scoped to your company — it can only access your company's recipients and notifications.

API Endpoints

Request body reference (POST /send)

Code Examples

🪝 Outbound webhooks

WardenPoint POSTs to your own systems when notification lifecycle events happen — acknowledgments, escalations, delivery failures. Subscribe your endpoints to the events you care about and react automatically: close tickets, update incidents, kick runbooks.

Available events

Subscribe to one or more events. WardenPoint sends a separate POST for each.

Common request envelope

Every event starts with the same envelope: event name, company UUID, and timestamp. Event-specific fields are merged in on top (see per-event schemas below).

Payload schemas per event

Exact contract for each of the 8 events. Fields prefixed `// optional` may be absent depending on channel.

Signature verification

Every request is signed with HMAC-SHA256 in the X-WardenPoint-Signature header. Always verify the signature before processing the payload — this guarantees the request came from WardenPoint and not from someone who happens to know your URL.

Request headers

Retries & dead-letter

If your endpoint returns non-2xx or times out, WardenPoint retries automatically:

• 5 attempts with 1s / 5s / 30s / 5min / 1h backoff.
• After the final failed attempt the delivery is marked "dead-letter" — visible in the dashboard.
• Hit "Replay" in the deliveries log to re-send a request after fixing the issue on your side.

📋 Alert templates

Save pre-built alert presets with placeholders once, then fire them from your code with one POST per slug. Variables come from the request body; the rest (recipient, priority, escalation policy) comes from the template.

When it helps

• The same alert message lives in 3-5 places in your codebase — centralise the wording.
• DevOps/runbook references a 'db_down' playbook — the slug becomes a public contract.
• You want to change alert wording without a re-deploy — edit the template body, version auto-bumps.

Fire a template

Pass in the body; backend substitutes them, applies the default priority/recipient, and ships through the same pipeline as /send.

Pinning to a version

Every save creates a new version. Existing callers keep working — add "version": N to the body to pin to a specific historical version.

Override defaults per-call

Pass an "override" object with priority, recipient_uuid and group_uuid keys in the body to swap any default for that single call.

Placeholder syntax

Mustache-lite — substitution only, no logic, no loops:

• {{ var }} — HTML-escaped (default; safe for any channel).
• {{{ var }}} — raw value, no escape. Your responsibility.
• No conditionals, no loops, no expressions — this is not a full templating engine.

🔑 Credentials & Setup

Most channels require external service credentials. Go to Dashboard → Settings → Credentials to configure them. Only email works out of the box — all other channels need setup.

💳 Plans & Billing

WardenPoint offers tiered plans. The Free plan includes Telegram and email; paid plans unlock PSTN voice calls, SMS, WhatsApp and Viber along with higher recipient/voice/SMS quotas and advanced features. The plan cards below are pulled from the live billing config.

Payment methods: credit/debit card via MonoPay or PayPal. Annual plans get a 20% discount. You can change your plan at any time — upgrade takes effect immediately, downgrade at the end of the billing period.

❓ FAQ