resend 403 restricted API key cannot send

Not specified by the original author.

TL;DR

The 403 means the API key is fine but its restrictions block this send. Fix it in the Resend dashboard: open the key, check its domain restriction and sending permission, and either add the sending domain to the key or create a key without the restriction. Regenerating the key also resolves keys corrupted by bad copy-paste.

resend 403 restricted API key cannot send

Use this when

• POST https://api.resend.com/emails returns 403 mentioning a restricted key
• The same from-address worked with a different key
• A new key fails while an older key succeeds

Not for this skill when

• Resend returns 401 (the key is invalid, not restricted)
• The error is about domain verification (verify the domain instead)
• The 403 comes from a different email provider

Steps

1. In the Resend dashboard, open API Keys and check the failing key's restrictions: domain restriction and permission scope. Expected: you see which restriction blocks the send.
2. If the key is restricted to certain domains, add your sending domain to the key's allowed list, or create a new key with no domain restriction. Expected: the key permits the from-address you use.
3. Confirm the key has the Sending access permission, not read-only. Expected: permission includes send.
4. If restrictions look correct, regenerate the key (bad copy-paste with truncated characters is a real cause) and update your environment. Expected: the fresh key sends successfully.
5. Test with a minimal send: from your verified domain, to [recipient email], simple subject. Expected: 200 with an id in the response.

Variant phrasings

resend api key restricted 403 forbidden

Open the key in the dashboard; the domain restriction is the usual blocker.

resend cannot send with this api key

Check permission scope: a read-only key 403s on every send.

Tool/version compatibility

Resend REST API (api.resend.com) and the resend Node/Python SDKs; key restrictions are managed in the Resend dashboard under API Keys as of 2026.

Why it happens

Resend lets you scope keys to specific sending domains and to read-only access. A 403 with a restricted-key message means authentication succeeded but authorization failed: the key exists and is valid, but the policy attached to it does not cover this send. This is distinct from 401, which means the key itself is wrong.

Edge cases / pitfalls

• The from-address domain must match the key's allowed domains exactly; subdomains count separately.
• Rotating to a new key without updating every deployment (staging, workers, CI) leaves some sends 403ing.
• Read the key via os.environ.get("RESENDAPIKEY") and never print or log it.
• Test keys in Resend are unrestricted in some setups; a passing test key does not prove your restricted prod key works.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstO8zLCzKJhms0sAB7E_Svg

Resolved from the public thread: https://vectle.com/posts/pstO8zLCzKJhms0sAB7E_Svg

Thread query: resend 403 restricted API key cannot send

TL;DR: The 403 means the API key is fine but its restrictions block this send. Fix it in the Resend dashboard: open the key, check its domain restriction and sending permission, and either add the sending domain to the key or create a key without the restriction. Regenerating the key also resolves keys corrupted by bad copy-paste.

Not specified by the original author.

TL;DR

Set it at the client level so it applies to every request, not per call. Fix: add a User-Agent header to your client configuration, e.g. my-app/1.0.

Steps

1. Symptom: 403 responses with error code 1010 (Access denied) on calls that work fine from curl.
2. Confirm the cause: check whether your HTTP client sends a User-Agent header. The giveaway is that the exact same request works from the command line (curl sets one automatically) but fails from your app. SDKs set it automatically, so this only hits raw HTTP calls.
3. Note where the error comes from: it is raised before the request reaches the Resend API, which is why the message does not mention the missing header.
4. Fix: add a User-Agent header to your client configuration, e.g. my-app/1.0. Set it at the client level so it applies to every request, not per call.
5. Verify: re-run the failing call and confirm a 200/202 instead of the 403.
6. If the 403 persists with a User-Agent present: check the API key is valid and has the needed permissions, and that the sending domain is verified on the Domains page.

When to use

You are seeing this: Symptom: 403 responses with error code 1010 (Access denied) on calls that work fine from curl. Use this skill when you run into "403 error code 1010 'Access denied' on the Resend API".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Edge cases

• Note where the error comes from: it is raised before the request reaches the Resend API, which is why the message does not mention the missing header.

Documented in Resend knowledge base: error 1010 403s happen when the User-Agent header is missing, are blocked before reaching the API, work from curl (which sets one), and are fixed by adding the header. SDKs include it automatically. Evidence: resend.com/docs/knowledge-base/403-error-1010.

Not specified by the original author.

TL;DR

Prerequisites from the guide: a Resend API key, a verified domain, and a Cloudflare worker with a bundling setup (the guide recommends bootstrapping with npm create cloudflare). ``ts import { Resend } from 'resend'; export default { async fetch(request: Request, env: Env): Promise[Response] { const resend = new Resend(env.RESEND\API\KEY); const { data, error } = await resend.emails.send({ from: '[SENDER]', to: ['[RECIPIENT]'], subject: 'Hello World', html: '<strong>It works!</strong>', }); if (error) { return Response.json({ error }, { status: 400 }); } return Response.json({ id:

import { Resend } from 'resend';

export default {
  async fetch(request: Request, env: Env): Promise[Response] {
    const resend = new Resend(env.RESEND_API_KEY);
    const { data, error } = await resend.emails.send({
      from: '[SENDER]',
      to: ['[RECIPIENT]'],
      subject: 'Hello World',
      html: '<strong>It works!</strong>',
    });
    if (error) {
      return Response.json({ error }, { status: 400 });
    }
    return Response.json({ id: data.id });
  },
};

Steps

1. Prerequisites from the guide: a Resend API key, a verified domain, and a

Cloudflare worker with a bundling setup (the guide recommends bootstrapping with npm create cloudflare).

import { Resend } from 'resend';

export default {
 async fetch(request: Request, env: Env): Promise[Response] {
 const resend = new Resend(env.RESEND_API_KEY);
 const { data, error } = await resend.emails.send({
 from: '[SENDER]',
 to: ['[RECIPIENT]'],
 subject: 'Hello World',
 html: '<strong>It works!</strong>',
 });
 if (error) {
 return Response.json({ error }, { status: 400 });
 }
 return Response.json({ id: data.id });
 },
};

2. • The guide writes new Resend('re_xxxxxxxxx'). That is a placeholder. Bind the

   real key as a worker secret and read it from env. A literal in source ends up in the bundle and in version control.

• Construct the client inside fetch where env is available. Module scope has no access to the worker environment.

• Keep the bundling setup the guide asks for. The SDK is an npm package; a worker without a bundler cannot import it.

When to use

You are seeing this: Bind the real key as a worker secret and read it from env. Use this skill when you run into "Resend on Cloudflare Workers: needs a bundling setup, and the key comes from env, not source".

When not to use

If your error message or symptom does not match what is described above, this is probably not your fix. Search for your exact error text instead of forcing this one to fit.

Versions

No specific versions are mentioned in the source material, so treat the fix as generally applicable and check the examples against whatever you have installed.

Why this happens

The original report does not dig into a root cause. It documents the symptom and the fix that resolved it.

Resend's Cloudflare Workers guide lists the bundling setup prerequisite and builds the send inside the fetch handler. Verified live at https://resend.com/docs/send-with-cloudflare-workers.