Partner quickstart

This guide is for partners: integrators offering email to their own customers with RQE underneath (reseller pattern). The model is: one customer, one project. You create a project per customer with your partner key, configure it entirely with that same key (domain, sender, webhook) and get back their API key to operate it. Each customer is genuinely isolated — their data, their domains, their limits and their stats.

Start here

The whole onboarding fits in one call with your partner key: the project, its sending domain with the complete DNS pack, and its sender. You don’t need the customer’s API key to configure them.

Compatibility: if you already integrated the previous flow, you don’t need to change anything. POST /v1/partner/projects with just { "name": "..." } is still valid and returns the same response as always; domain and sender are new, optional fields. The /domains/* endpoints called with the customer’s API key didn’t change either.

Create the whole customer

With your partner key (sk_partner_..., issued by RQE when your partner account is enabled):

curl -X POST https://api.reallyquickemails.com/v1/partner/projects \
  -H "Authorization: Bearer sk_partner_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Customer",
    "external_key": "your-internal-id",
    "domain": "customer.com",
    "sender": { "name": "Customer", "email": "hello@customer.com" },
    "webhook_url": "https://yourapp.com/hooks/rqe"
  }'

{
  "project_id": "…",
  "slug": "customer",
  "api_key": "sk_proj_…",
  "domain": {
    "domain": "customer.com",
    "identity_id": "…",
    "verification_status": "pending",
    "can_send": false,
    "verification_url": "https://app.reallyquickemails.com/verificar-dominio/…",
    "reply_domain": { "domain": "reply.customer.com", "status": "pending" },
    "tracking_domain": { "domain": "links.customer.com", "status": "pending" },
    "records": [ "…11 records: verification, 3 DKIM, SPF, DMARC, return path, tracking and reply…" ]
  },
  "sender": { "id": "…", "from_email": "hello@customer.com", "sender_source": "manual", "domain_authenticated": false }
}

Store the api_key securely: it’s returned only once. The external_key makes the call idempotent — retrying it returns the same project instead of duplicating it.domain and sender go together. SES won’t register a domain without a From address, so sending one without the other returns 400 before anything is created. Every DNS record carries an fqdn, the ready-to-publish name; that’s the one the customer copies.Full reference in Partner / Provisioning.

Forward the verification link

domain.verification_url is a public page with the customer’s DNS records, copy buttons and a verify button. Your end customer opens it without an RQE account: it’s the only thing you have to send them.If their DNS provider supports Domain Connect, publishing is one click from that same page.

This is the step where most integrations stall: the end customer has to touch their DNS. The public link is what helps most — don’t ask them to copy records out of an email from you.

Wait for verification

When the customer publishes DNS, you get the domain.verified webhook — no polling needed. See Webhooks.To force the check when they tell you “it’s configured”:

curl -X POST https://api.reallyquickemails.com/v1/partner/projects/{project_id}/domains/customer.com/verify \
  -H "Authorization: Bearer sk_partner_xxxxxxxxxxxx"

Send and measure

With the customer’s api_key, send transactional or bulk. To see how each one is doing:

curl https://api.reallyquickemails.com/v1/partner/projects/{project_id}/stats \
  -H "Authorization: Bearer sk_partner_xxxxxxxxxxxx"

And GET /v1/partner/projects lists your whole portfolio.

Configure a customer that already exists

Everything the full onboarding does can be done later, piece by piece, always with the partner key:

I want to…	Endpoint
Register their domain	`POST /v1/partner/projects/{id}/domains` (with `sender`)
See record-by-record status	`GET /v1/partner/projects/{id}/domains/{domain}`
Create a sender	`POST /v1/partner/projects/{id}/senders`
Change name or webhook	`PATCH /v1/partner/projects/{id}`
Rotate their API key	`POST /v1/partner/projects/{id}/api-key/rotate`
Reactivate a disabled one	`POST /v1/partner/projects/{id}/reactivate`
Check your client quota	`GET /v1/partner/whoami` → `partner.max_projects`

Domain registration never overwrites what already works. If the domain was already registered, the call is idempotent and touches nothing else about the customer. And even for a new domain, it won’t register reply if the customer already has a verified one, nor tracking if one is already configured: registering a reply domain rewrites its status to pending, which would switch off branded replies for a customer already running them. Whatever was skipped comes back in the response’s skipped[] array, with its step and reason_code. See Skipped steps.

If your customer doesn’t control their DNS

There is a way out: verify just the mailbox, by email (magic link). You have to ask for it explicitly:

curl -X POST https://api.reallyquickemails.com/v1/partner/projects/{project_id}/senders \
  -H "Authorization: Bearer sk_partner_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{ "name": "Customer", "email": "hello@gmail.com", "allow_unauthenticated": true }'

Without the flag, the API answers 422 DOMAIN_NOT_VERIFIED. That’s on purpose. That requirement belongs only to the new endpoint POST /v1/partner/projects/{id}/senders. If you verify senders today with POST /domains/verify-email and the customer’s API key, that path keeps working the same, with no flag and no such error.

The magic link is not for volume. It verifies the mailbox, not the domain: mail goes out signed with the platform’s shared domain, so Microsoft rejects with 5.7.515 on DMARC fail and Gmail answers 550-5.7.1 "likely unsolicited mail". It also unlocks neither reply domain nor tracking domain.None of this shows up as an error in your integration: the API returns 200 and the problem surfaces weeks later in the bounce rate.

Check your customers’ health

GET /domains/health returns, for every domain in a project: whether it can send, how its authentication looks, how much it sent, how it bounces, and what’s missing — in text you can forward straight to your customer.

curl "https://api.reallyquickemails.com/domains/health" \
  -H "Authorization: Bearer sk_proj_xxxxxxxxxxxx"

{
  "summary": { "total": 3, "healthy": 1, "warning": 1, "critical": 1 },
  "data": [
    {
      "domain": "customer.com",
      "status": "critical",
      "can_send": true,
      "sent": 4501,
      "hard_bounce_rate": 0.42,
      "issues": ["Verificado solo por email (un click), sin dominio: no permite DKIM propio, reply domain ni tracking domain."]
    }
  ]
}

Watch for can_send: true with status: critical. Email goes out with a 200 and nothing looks broken, but it ships without DKIM on your customer’s domain — their reputation blends with everyone else’s, and they can’t use their own reply domain or tracking domain.It’s the single most common gap in partner integrations, and it doesn’t surface as an error anywhere else.

See Domains for the full response. With the partner key you get the same per customer, without their API key: GET /v1/partner/projects/{id} returns a health block with status, can_send, hard_bounce_rate and issues. It’s the call you build your customer panel on.

Watch hard_bounce_rate, not the total bounce count. Providers calculate the suspension threshold (~5%) on permanent bounces; transient ones don’t count. A domain can show 12% total bounces while staying below 1% hard bounce.Also ask each customer to publish DKIM on their own domain: that’s what makes their sending reputation theirs, rather than blending with everyone else’s.

Alternative — several customers in one project

If you’d rather manage a single credential and your customers will never need their own limits or access, you can keep them all inside one project.

	One project per customer	Several customers, one project
Credential	`sk_partner_` + one per customer	a single `sk_proj_`
Domain and reply domain per customer	yes	yes
Per-customer metrics	`/v1/partner/projects/:id/stats`	`/v1/domain-stats`
Per-customer rate limits	yes	no, project-wide
Your customer signs into RQE	yes	not possible

In that model registering domains and reply domains works the same, just with your own key. A project can hold several reply domains: each send resolves the one matching the sender’s domain. To debug a specific customer:

curl "https://api.reallyquickemails.com/v1/activity?sender_domain=customer.com&status=bounced" \
  -H "Authorization: Bearer sk_proj_xxxxxxxxxxxx"

And for their aggregated metrics, GET /v1/domain-stats — see Activity. GET /domains/health works here too, and returns one entry per customer domain.

With an AI agent (MCP)

{
  "mcpServers": {
    "reallyquickemails-partner": {
      "url": "https://mcp.reallyquickemails.com/mcp",
      "headers": { "Authorization": "Bearer sk_partner_xxxxxxxxxxxx" }
    }
  }
}

See MCP · partner mode.

Reference

Domains — registration, verification, health, reply domain and tracking domain.
Activity — ?sender_domain= and /v1/domain-stats.
Public API — sending.
Webhooks — domain.verified and email events.
Partner / Provisioning — full reference for /v1/partner/*: onboarding, domains, senders, API key and error codes.

Guides

The app

Concepts

API Reference

Start here

Configure a customer that already exists

If your customer doesn’t control their DNS

Check your customers’ health

Alternative — several customers in one project

With an AI agent (MCP)

Reference

​Start here

​Configure a customer that already exists

​If your customer doesn’t control their DNS

​Check your customers’ health

​Alternative — several customers in one project

​With an AI agent (MCP)

​Reference

Start here

Configure a customer that already exists

If your customer doesn’t control their DNS

Check your customers’ health

Alternative — several customers in one project

With an AI agent (MCP)

Reference