Authentication

Your endpoint might need to verify that a request is actually coming from QuzenixCron, not some random caller. Here are the most common ways to do that.

Bearer Token

The most common approach. Add a custom header:

Authorization: Bearer your-secret-token-here

Then validate it in your backend. Use a long random token (32+ character UUID or hex string) — nothing guessable.

API Key

If your service uses a custom API key header:

X-API-Key: sk_live_xxxxxxxxxxxxxxxxxxxxxxxx

Webhook Signature (Recommended)

For highly sensitive endpoints, you can validate the origin via an IP allowlist or a signature header. QuzenixCron doesn't send automatic request signatures yet (it's on the roadmap), so for now bearer tokens or IP allowlists are your best options.

Don't put secrets in the URL

Avoid putting tokens in the URL (e.g., ?token=xxx). URLs end up in proxy logs, CDN logs, and your server logs — that's a lot of places to leak a secret. Use a header instead.

Example: Securing a Telegram Bot Webhook

The Telegram Bot API already uses a unique secret URL per bot (e.g., https://yourbot.com/webhook/{random-token}). If you're just using QuzenixCron for keepalive pings rather than message delivery, a simple /healthz endpoint without a secret is fine.

Example: Discord Webhooks

A Discord webhook URL is itself a secret — anyone with the URL can post to it. Treat it like a password: don't share it, don't commit it to a public repo.

SSRF Protection in QuzenixCron

QuzenixCron automatically blocks requests to private and internal IPs (10.x, 192.168.x, 172.16–31.x, localhost, AWS metadata at 169.254.169.254). You can't use QuzenixCron as a proxy to reach internal networks. See the Security page for details.

PreviousHTTP Request Next Timezones