Why am I getting an invalid_access error?

A 422 invalid_access means your request authenticated fine — the API key is valid — but the key does not have permission for the action you tried. This is the single most common cause: using a sending-only key (sending_access) to manage resources.

{
  "statusCode": 422,
  "name": "invalid_access",
  "message": "This API key does not have permission for this action."
}

Cause 1 — a sending-only key managing resources

API keys come in two permission levels:

If you call an endpoint like POST /domains, DELETE /audiences/:id, or POST /api-keys with a sending_access key, you get 422 invalid_access. The fix is to use a full_access key for management calls and reserve the sending_access key for POST /emails.

Cause 2 — an unverified from-domain (also a 422)

A frequent point of confusion: sending from a domain you have not verified returns a 422 validation_error, because the request body itself is rejected before any permission check on the resource.

{
  "statusCode": 422,
  "name": "validation_error",
  "message": "The domain is not verified. Verify it before sending."
}

You can only send from a domain (or a subdomain of a domain) you have added and verified by publishing its SPF/DKIM/DMARC DNS records. If the from address is not even a valid email, you instead get 422 invalid_from_address. See the full Errors reference for every name and status code.

Cause 3 — new-account sending restrictions

A brand-new account starts in a restricted review mode until production access is granted. While in review mode:

• You can only send to verified recipient addresses — sending to an arbitrary recipient is rejected.
• Daily send volume and send rate are capped to small starter limits.
• Your verified from-domain still works, but the recipient must also be verified.

Cause 4 — a missing User-Agent header

This one bites people who hand-roll HTTP requests (the official `mailblastr` SDK sets a User-Agent for you, so SDK users never hit this). Every call to the API surface (/emails, /domains, /audiences, /campaigns, and the rest) must include a User-Agent header. A request without one is rejected with a 403 before it reaches the endpoint logic:

{
  "statusCode": 403,
  "name": "validation_error",
  "message": "All API requests must include a User-Agent header."
}

This is confusing because the same request often works from curl (which sets a User-Agent automatically) but fails from a fetch/library call that omits it. The fix is simply to send a descriptive User-Agent:

curl -X POST 'https://api.mailblastr.com/emails' \
  -H 'Authorization: Bearer mb_xxxxxxxxx' \
  -H 'Content-Type: application/json' \
  -H 'User-Agent: my-app/1.0' \
  -d '{
    "from": "you@yourdomain.com",
    "to": "user@example.com",
    "subject": "Hello",
    "html": "<p>Hello</p>"
  }'

Checklist

1. 1
   Confirm the key permission

   If you are calling a management endpoint, use a full_access key. A sending_access key sending to POST /emails is fine; managing domains/audiences/keys with it returns 422 invalid_access.

2. 2
   Send a User-Agent header

   If you get a 403 validation_error mentioning User-Agent, your HTTP client is omitting the header. Add a descriptive User-Agent to every request.

3. 3
   Verify the from-domain

   If you are sending and the error is 422 validation_error about the domain, finish DNS verification first — and make sure the from matches your verified domain exactly (subdomain included). That is a separate problem from a permission error.

4. 4
   Check production access

   If sends only work to verified recipients, request production access to leave review mode.