The Nateq API authenticates with API keys passed as a Bearer token:
Authorization: Bearer tg_live_your_key_here
Environments
| Prefix | Environment | Notes |
|---|
tg_live_ | Production | Acts on real data |
tg_test_ | Sandbox | Isolated test environment |
Scopes
Keys are granted scopes that gate what they can do. A request to an endpoint
whose scope the key lacks returns 403 INSUFFICIENT_SCOPE. Grant the minimum a
key needs.
| Scope | Grants |
|---|
conversations:read / conversations:write | Conversations, messages, categories, and CRM (contacts, companies, leads) |
tickets:read / tickets:write | Support tickets and replies |
tags:read / tags:write | Tags |
teams:read | Teams |
templates:read / templates:write | Message templates and attributes |
broadcasts:read / broadcasts:write | Broadcasts |
faqs:read / faqs:write | FAQs and help center content |
files:read / files:write | File attachments |
overview_stats:read | Analytics and statistics |
webhooks:manage | Outgoing webhook subscriptions |
Account, billing, user-management, RBAC, and AI-builder endpoints can’t be
reached with an API key at all — calling one returns 403 ENDPOINT_NOT_PUBLIC.
Use the dashboard for those.
Keeping keys safe
Treat keys like passwords. Never commit them or expose them in client-side code —
the API is meant to be called from your server.
- Restrict a key to known IPs (allow-list) where possible.
- Rotate keys periodically; revoke any that leak from the dashboard.
- Use a sandbox (
tg_test_) key for development.
