API keys

An API key lets a server send submissions to Expeed Relay on behalf of one of your sites. Use it when the thing submitting is a backend — an order confirmation from your e-commerce system, a nightly report, an internal tool — rather than a visitor filling in a form in their browser.

Browser submissions do not use API keys at all. Those are authorised by the site’s Allowed origins list and protected by CAPTCHA, because a key embedded in a public web page would be readable by anyone. If someone asks for a key for an ordinary contact form, that is the wrong mechanism.

Every key belongs to exactly one site and is rejected if used to submit for another, so a leaked key never reaches beyond the site it was issued for.

A key cannot send to arbitrary addresses

A server using an API key may name the recipients for a particular send, but only from the addresses you have already configured on that site’s forms. Anything else is refused outright, with an error naming the address it would not send to.

This is the important limit to understand, because it is what makes a leaked key survivable. A caller with a key also controls the subject and body of the message. If they could also choose the destination, the key would be a way to send arbitrary content to arbitrary strangers from your verified sending domain — mail that passes your SPF and DKIM checks and inherits your reputation. Restricting the destinations to the ones an operator consciously added closes that off.

If a developer reports a recipient being rejected, the fix is in Expeed Relay, not in their code. Add the address on the relevant form’s Recipients tab first — see Forms & recipients — and only then have them retry. Deleting a recipient also revokes the server’s ability to send to it, so check with whoever runs the integration before you remove one.

A server that names no recipients at all falls back to the form’s configured recipient list, which is usually what you want — and it is the only way to get webhooks fired.

Two limits worth knowing before you design an integration

The check matches the address, not the channel. Expeed Relay confirms that the address appears somewhere in the site’s recipient list; it does not confirm that you configured that address for the channel the server is asking to send on. An address you added as an email recipient will therefore be accepted for a WhatsApp send too, and the delivery will simply fail later as a job. If a job fails with an address that looks correct, check which channel the recipient was actually created for.

Naming recipients explicitly turns webhooks off for that send. Your Slack and Teams destinations are not recipients — they live with the form as webhooks, and the allowlist is built only from recipients. So a server that names its recipients gets exactly those and no webhook post, and it cannot ask for a webhook by name either. If a team relies on a Slack channel seeing everything, have the integration send without naming recipients, so the form’s full configuration applies.

This is the most likely reason a Slack channel goes quiet while emails keep arriving. Nothing is broken and nothing appears as a failed job — the webhook was never queued. Check whether the server started naming its recipients. See Webhooks.

Issue a key

1. Open API Keys in the left sidebar. Keys are grouped under the site they belong to, with the key count beside each site name.
2. Click Create API key.
3. Enter a Name that says who is using it, like “Production checkout server” — it is the only clue you will have later about what the key is for.
4. Choose the Site the key may submit for.
5. Optionally set an Expiry date. Leave it blank and the list shows Never. An expired key stops working on its own, with no warning.
6. Click Create API key, then copy the value from the Your new API key dialog before you close it.

Screenshot to come

The API Key Created dialog showing the full key once, with the warning that it will not be shown again and a copy button

The key is shown exactly once. Expeed Relay stores only a hash of it, so nobody — not you, not an admin, not support — can retrieve the value once that dialog closes. The list afterwards shows only the name, dates, and status. If a key is lost, issue a replacement and revoke the old one.

Rotate a key without downtime

Order matters here. Never revoke first.

1. Issue a new key for the same site.
2. Give the new value to whoever runs the server, and have them deploy it.
3. Confirm traffic has moved — check Submissions & jobs for successful submissions after the deploy.
4. Only then revoke the old key.

Rotate on a schedule, and immediately whenever someone with access to the value leaves.

Revoke a key

Find the key under its site and click Revoke, then confirm. It stops working straight away and its Status becomes Revoked, but the row stays so you keep the record. The trash icon deletes the row outright — use that only for tidying up long-dead keys, since it destroys the audit trail.

Admins and managers can manage keys. Managers only see and issue keys for the sites they are assigned to; admins see every site. Viewers have no access to this page at all. See Users & roles.

Related

• Creating a site — a key is always issued against a site, so create one first
• Users & roles — who can issue and revoke keys, and for which sites