Authenticate API requests
Create an API key, pick the right scopes, and read the responses the API sends back.
NevarMail supports two authentication methods: session-based authentication for the dashboard, and API key authentication for programmatic access.
Session authentication
When you sign in through the NevarMail dashboard, a session cookie is automatically managed. All requests from the dashboard UI use this session for authentication. No additional configuration is required.
A signed-in session can also call the /api/v1/* endpoints documented here: where an API key is checked for a scope, a session is authorized against your role's permissions instead. That is what lets the dashboard call the same endpoints your integration does.
The reverse is not true — API keys cannot be used against dashboard-only routes, which answer 403 SESSION_ONLY. A few surfaces are bearer-only in the other direction and reject sessions outright: the MCP endpoint and the internal staff API.
For an integration, use an API key: it is scoped, revocable, and not tied to a person who might leave.
API key authentication
For programmatic access, include your API key in the request headers against the /api/v1/* endpoints:
curl -X POST https://app.nevarmail.com/api/v1/email/send \
-H "Content-Type: application/json" \
-H "Authorization: Bearer YOUR_API_KEY" \
-d '{"to":"user@example.com","subject":"Hello","text":"Hi there"}'For local development, use http://localhost:3400 in place of https://app.nevarmail.com.
Generating API keys
API keys can be generated from the Settings page in the dashboard. Each key can be scoped to specific permissions.
Key scopes
| Scope | Description |
|---|---|
email:send | Send Email -- gates single sends, scheduled sends, and list sends |
templates:read | Templates (read) |
templates:write | Templates (write) |
senders:read | Senders (read) |
senders:write | Senders (write) |
analytics:read | Analytics (read) |
campaigns:read | Campaigns (read) |
lists:read | Lists (read) |
lists:write | Lists (write) |
sequences:read | Sequences (read) |
sequences:write | Sequences (write) |
domains:read | Domains (read) |
domains:write | Domains (write) |
contacts:read | Contacts (read) |
contacts:write | Contacts (write) |
providers:read | Providers (read) |
org:read | Organization (read) |
org:write | Organization (write) |
inbox:read | Inbox (read) |
inbox:send | Inbox (send) |
webhooks:read | Webhook endpoints (read) |
webhooks:write | Webhook endpoints (write) |
* | Full access (all scopes) |
Request headers
All API requests should include:
| Header | Required | Description |
|---|---|---|
Content-Type | Yes (POST/PUT) | Must be application/json |
Authorization | Yes | Bearer YOUR_API_KEY |
Response format
Success responses use a standard envelope with the result under data, a requestId for support/debugging, and pagination on list endpoints:
{
"data": { "id": "...", "status": "sent" },
"requestId": "req_...",
"pagination": { "page": 1, "perPage": 25, "total": 3 }
}Error responses always return an error field with a human-readable message. Most errors also include a machine-readable code and the requestId; an invalid API key returns only error, with no code field:
{
"error": "Template not found",
"code": "NOT_FOUND",
"requestId": "req_..."
}{
"error": "Invalid API key"
}Error codes
| Code | Meaning |
|---|---|
(no code field) | Invalid or missing API key -- response is {"error": "Invalid API key"} with a 401 status and no code |
SCOPE_DENIED | The API key's granted scopes do not include the scope the endpoint requires |
PERMISSION_DENIED | The caller's role does not hold the RBAC permission the action requires |
VALIDATION_ERROR | The request body failed schema validation |
NOT_FOUND | The requested resource does not exist (or is not visible to this org) |
RATE_LIMITED | This key has used its per-minute allowance -- 429, with Retry-After |
SESSION_ONLY | The route only accepts a signed-in browser session, not an API key -- 403. Use the /api/v1/ equivalent |
Rate limiting
API-key requests are limited to 60 per minute per key, regardless of plan; an individual key can be given a higher limit on request. See Rate Limits for the headers and how to back off.
Security best practices
- Rotate keys regularly -- Generate new API keys periodically and revoke old ones
- Use minimal scopes -- Only grant the permissions each key actually needs
- Keep keys secret -- Never expose API keys in client-side code or public repositories
- Use environment variables -- Store keys in environment variables, not in code
How do unsubscribes and suppression work?
What NevarMail handles automatically for unsubscribes and suppression, and what stays your responsibility as the sender of record.
What recipient data does NevarMail actually store?
NevarMail is built to minimize recipient data on its systems and keep it in your own accounts wherever possible — here's exactly what is and isn't stored, by feature.