> ## Documentation Index > Fetch the complete documentation index at: https://docs.brudcast.com/llms.txt > Use this file to discover all available pages before exploring further. # Sending keys > The credential the email send API requires: how to create one, the provisioning wait, and how it differs from a platform API key. A sending key is the credential the [email send API](/developers/sending/http-api) requires. You send it to `POST https://mailing-service.prod.brudcast.com/api/v1/send` as `Authorization: Bearer `. It does nothing on the platform API. **Before you start**, you need your own verified sending domain. The **Brudcast trial address** has no sending keys and no SMTP credentials. See [Add a sending domain](/channels/email/add-a-sending-domain) and [Verify your domain](/channels/email/verify-your-domain). ## What a sending key is | | | | ---------- | --------------------------------------------------------------- | | Surface | The email send API only | | Host | `mailing-service.prod.brudcast.com` | | Sent as | `Authorization: Bearer `. The send API ignores `X-API-Key` | | Looks like | `bk_live_` followed by 64 hex characters | | Created in | **Channels > Email**, the domain, its **Sending Keys** tab | | Can do | Send mail from its own domain. Nothing else | A sending key carries one permission, `messages:send`, and it can't be changed. It can't read your contacts, change a domain or reach billing. That's the reason to prefer it over a platform API key in an application that only sends mail. A sending key and a platform API key have the same shape: `bk_live_` followed by 64 hex characters. You can't tell them apart by looking at them. Keep the sending key in `BRUDCAST_SENDING_KEY` and the platform API key in `BRUDCAST_API_KEY`, and never reuse one name for both. See [Authentication](/developers/authentication). ## One key, one domain A domain sending key sends only from the domain it was created on. A `from` address on any other domain fails: ``` 400 From address domain 'mail.other-example.com' does not match sending key domain 'mail.example.com' ``` If one application sends from several of your domains, either hold one key per domain, or create a platform API key with **Messages** set to **Full access**, which carries `messages:send` and can send from any sending domain your organization owns. | | Domain sending key | API key with **Send Messages** | | ------------- | --------------------------------- | ---------------------------------------- | | Created in | The domain's **Sending Keys** tab | **Developers > API Keys** | | Sends from | Only its own domain | Any sending domain the organization owns | | Also works on | Nothing | The platform API, with its other scopes | | If it leaks | Mail from one domain | Everything its scopes allow | ## Create a sending key Go to **Channels > Email**, open the **Domains** tab, select your domain, then select the **Sending Keys** tab. Select **Add Sending Key**, enter a **Description** naming the application that will hold it, then select **Create Key**. The **Sending Key Created** dialog shows the **API Key ID** and the **API Secret Key**. The secret is shown once and Brudcast stores only a hash of it, so copy it into your secret store before you close the dialog. The dashboard walkthrough, with screenshots, is in [Sending keys](/channels/email/domain-api-keys) in the Guides tab. ### Wait for `active` A new or regenerated key isn't usable straight away. It appears as **Provisioning** while the send API receives it, then turns **Active**. | Status | Meaning | | --------------------- | ---------------------------------------------------------------------------- | | `provisioning` | Just created or regenerated. The send API rejects it with `401 Unauthorized` | | `active` | Ready to send | | `provisioning_failed` | The send API never received the key. Regenerate it, or create another | A send with a key that's still provisioning fails the same way as a wrong key, so check the **Status** column before you debug anything else. ## Use it ```bash theme={"system"} export BRUDCAST_SENDING_KEY="your_sending_key" ``` ```bash theme={"system"} curl -X POST https://mailing-service.prod.brudcast.com/api/v1/send \ -H "Authorization: Bearer $BRUDCAST_SENDING_KEY" \ -H "Content-Type: application/json" \ -d '{ "from": { "name": "Example", "address": "hello@mail.example.com" }, "to": [{ "address": "jane@example.com" }], "subject": "Your receipt", "text": "Thanks for your order.", "html": "

Thanks for your order.

" }' ``` Node.js, Python and PHP versions of the same call are in the [email send API](/developers/sending/http-api#example) reference. ## Regenerate a key Open the key's menu on the **Sending Keys** tab and select **Regenerate Secret Key**. The new secret is shown once, the old one stops working immediately, and the key goes back to `provisioning` until the send API has it. For a rotation with no failed sends, create a second key, deploy it everywhere, then delete the first. ## Delete a key Open the key's menu and select **Delete**. Anything still using it fails on its next request with `401 Unauthorized`. Delete a key as soon as you suspect it has leaked, then create a new one. ## How it differs from a platform API key | | Sending key | Platform API key | | ------------------------------------------------------- | ----------------------------------- | --------------------------------------- | | Host | `mailing-service.prod.brudcast.com` | `core-service.prod.brudcast.com` | | Header | `Authorization: Bearer` only | `X-API-Key`, or `Authorization: Bearer` | | Scope | Fixed at `messages:send` | Any of 18 scopes you choose | | Bound to | One sending domain | One organization | | Managed in | **Channels > Email**, the domain | **Developers > API Keys** | | Expiry, IP allowlist, request logs, per-key rate limits | No | Yes | Sending a sending key to the platform API fails with `401` and `Unauthorized access`, because the platform API doesn't know the key. See [Using the wrong credential on the wrong host](/developers/errors#using-the-wrong-credential-on-the-wrong-host). ## Related Every field, attachments, headers and errors. Which credential works on which surface, and how to send it. The walkthrough, with screenshots. Platform API keys, scopes and organization-wide sending.