Quickstart
1. Create a workspace key
Open the Keys page in the dashboard and create a
key. You’ll get an rray_live_... (or rray_test_...) secret — store it
safely, it is shown exactly once.
A workspace key is bound to one workspace, so it needs no workspace header. Every request authenticates with a Bearer header:
2. Send a message
Use a from address on a sending domain you’ve added in the dashboard — that
is what lets us DKIM-sign the message. The API won’t reject an unknown domain,
but unsigned mail is very likely to be rejected by the recipient’s provider.
to is an array; cc, bcc, reply_to and attachments are optional.
A 202 Accepted returns the message id and nothing else — the message has been
accepted for delivery, not yet delivered:
Two headers worth understanding before production:
Idempotency-Key— makes retries safe; see Idempotency.RRay-Workspace-Id— required only when you authenticate with a platform key. A workspace key rejects it; see Credentials.
Send responses also carry RRay-Quota-Limit, RRay-Quota-Remaining and
RRay-Quota-Reset, reporting your plan’s monthly and daily allowance as
structured-field dictionaries.
To send up to 100 messages in one request, POST /v1/messages/batch with a
JSON array of the same message objects. Every ceiling the API enforces — batch
size, attachment budget, rate limits, retention — is listed on
Limits & facts.
3. Track delivery
Statuses progress accepted → queued → delivered, or end in bounced,
deferred or failed — Message lifecycle
explains what each one means and what to do about it. Poll one message:
Or list recent messages with a filter:
List responses are cursor-paginated — follow pagination.next_cursor for
older messages, pagination.prev_cursor for newer ones
(how it works). You can also filter by id,
recipient and created_at.
If something goes wrong
Errors are flat application/problem+json bodies with a stable code to
match on and a request_id to quote to support:
The full catalog lives at GET /errors and in
the Errors guide.