Partner quickstart

Esta guía es para partners: integradores que ofrecen email a sus propios clientes usando RQE por debajo (patrón reseller). El modelo es: un cliente, un proyecto. Creas un proyecto por cada cliente con tu partner-key, lo configuras entero con esa misma key (dominio, remitente, webhook) y recibes su API key para operarlo. Cada cliente queda aislado de verdad — sus datos, sus dominios, sus límites y sus estadísticas.

Empieza acá

El alta entera cabe en una llamada con tu partner-key: el proyecto, su dominio de envío con el pack DNS completo y su remitente. No necesitas la API key del cliente para configurarlo.

Compatibilidad: si ya integraste el flujo anterior, no necesitas cambiar nada. POST /v1/partner/projects con solo { "name": "..." } sigue siendo válido y devuelve la misma respuesta de siempre; domain y sender son campos nuevos y opcionales. Los endpoints de /domains/* con la API key del cliente tampoco cambiaron.

Crea el cliente completo

Con tu partner-key (sk_partner_..., la emite RQE al habilitar tu cuenta de partner):

curl -X POST https://api.reallyquickemails.com/v1/partner/projects \
  -H "Authorization: Bearer sk_partner_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Cliente",
    "external_key": "tu-id-interno",
    "domain": "cliente.com",
    "sender": { "name": "Cliente", "email": "hola@cliente.com" },
    "webhook_url": "https://tuapp.com/hooks/rqe"
  }'

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

Guarda la api_key de forma segura: se devuelve una sola vez. El external_key hace la llamada idempotente — reintentarla devuelve el mismo proyecto en vez de duplicarlo.domain y sender van juntos. SES no registra un dominio sin una dirección From, así que mandar uno sin el otro responde 400 antes de crear nada. Cada registro DNS trae fqdn, que es el nombre listo para publicar; ese es el que copia el cliente.Referencia completa en Partner / Provisioning.

Reenvía el link de verificación

domain.verification_url es una página pública con los registros DNS del cliente, botones de copiar y un botón de verificar. La abre tu cliente final sin cuenta RQE: es lo único que tienes que mandarle.Si su proveedor de DNS soporta Domain Connect, la publicación es de un clic desde esa misma página.

Este es el paso donde se traba la mayoría de las integraciones: el cliente final tiene que tocar su DNS. El link público es lo que más ayuda — no le pidas que copie registros de un correo tuyo.

Espera la verificación

Cuando el cliente publique el DNS, recibes el webhook domain.verified — no hace falta pollear. Ver Webhooks.Para forzar el chequeo cuando te diga “ya lo configuré”:

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

Envía y mide

Con la api_key del cliente, envía transaccional o en lote. Para ver cómo va cada uno:

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

Y GET /v1/partner/projects lista toda tu cartera.

Configura un cliente que ya existe

Todo lo que hace el alta completa se puede hacer después, por separado y siempre con la partner-key:

Quiero…	Endpoint
Registrar su dominio	`POST /v1/partner/projects/{id}/domains` (con `sender`)
Ver el estado registro a registro	`GET /v1/partner/projects/{id}/domains/{domain}`
Crear un remitente	`POST /v1/partner/projects/{id}/senders`
Cambiar nombre o webhook	`PATCH /v1/partner/projects/{id}`
Rotar su API key	`POST /v1/partner/projects/{id}/api-key/rotate`
Reactivar uno deshabilitado	`POST /v1/partner/projects/{id}/reactivate`
Ver tu cupo de clientes	`GET /v1/partner/whoami` → `partner.max_projects`

El alta de dominio no pisa lo que ya funciona. Si el dominio ya estaba registrado, la llamada es idempotente y no toca nada más del cliente. Y aunque el dominio sea nuevo, no registra el reply si el cliente ya tiene uno verificado, ni el tracking si ya tiene uno configurado: registrar un reply domain reescribe su estado a pending, y eso le apagaría las respuestas branded a un cliente que ya las tenía andando. Lo que se omitió viene dicho en el array skipped[] de la respuesta, con su step y su reason_code. Ver Pasos omitidos.

Si tu cliente no controla su DNS

Existe la salida de verificar solo la casilla, por correo (magic link). Hay que pedirla explícitamente:

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": "Cliente", "email": "hola@gmail.com", "allow_unauthenticated": true }'

Sin el flag, la API responde 422 DOMAIN_NOT_VERIFIED. Es a propósito. Esa exigencia es solo del endpoint nuevo POST /v1/partner/projects/{id}/senders. Si hoy verificas remitentes con POST /domains/verify-email y la API key del cliente, ese camino sigue funcionando igual, sin flag y sin este error.

El magic link no sirve para volumen. Verifica la casilla, no el dominio: el correo sale firmado con el dominio compartido de la plataforma, así que Microsoft rechaza con 5.7.515 por DMARC fail y Gmail responde 550-5.7.1 "likely unsolicited mail". Tampoco habilita reply domain ni tracking domain.Nada de esto aparece como error en tu integración: la API responde 200 y el problema se ve semanas después en la tasa de rebote.

Revisa la salud de tus clientes

GET /domains/health devuelve, por cada dominio del proyecto: si puede enviar, cómo está su autenticación, cuánto envió, cómo rebota y qué le falta — en texto que puedes reenviar directo a tu cliente.

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

{
  "summary": { "total": 3, "healthy": 1, "warning": 1, "critical": 1 },
  "data": [
    {
      "domain": "cliente.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."]
    }
  ]
}

Presta atención a can_send: true con status: critical. El correo sale con 200 y nada parece roto, pero va sin DKIM del dominio de tu cliente — su reputación se mezcla con la de todos y no puede usar reply domain ni tracking domain propios.Es el hueco más común en las integraciones de partner, y no aparece como error en ningún otro lado.

Ver Dominios para la respuesta completa. Con la partner-key tienes lo mismo por cliente, sin su API key: GET /v1/partner/projects/{id} devuelve un bloque health con status, can_send, hard_bounce_rate e issues. Es la llamada con la que armas tu panel de clientes.

Mira el hard bounce, no el total de rebotes. Los proveedores calculan el umbral de suspensión (~5%) sobre los rebotes permanentes; los temporales no cuentan. Un dominio puede mostrar 12% de rebote total y estar por debajo del 1% de hard bounce.Y pide a cada cliente que publique el DKIM de su propio dominio: es lo que hace que su reputación de envío sea suya y no se mezcle con la de los demás.

Alternativa — varios clientes en un proyecto

Si prefieres gestionar una sola credencial y tus clientes nunca van a necesitar límites ni acceso propios, puedes tenerlos a todos dentro de un proyecto.

	Un proyecto por cliente	Varios clientes en un proyecto
Credencial	`sk_partner_` + una por cliente	una sola `sk_proj_`
Dominio y reply domain por cliente	sí	sí
Métricas por cliente	`/v1/partner/projects/:id/stats`	`/v1/domain-stats`
Rate limits por cliente	sí	no, del proyecto entero
Tu cliente entra al dashboard RQE	sí	no es posible

En ese modelo el alta de dominios y reply domains es igual, pero con tu propia key. Un proyecto puede tener varios reply domains: cada envío resuelve el que corresponde al dominio del remitente. Para depurar un cliente concreto:

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

Y para sus métricas agregadas, GET /v1/domain-stats — ver Activity. GET /domains/health también funciona acá, y devuelve una entrada por cada dominio de cliente.

Registra el dominio de tu cliente

Con la API key de tu proyecto, das de alta el dominio de cada cliente y recibes los registros DNS que debe publicar.

curl -X POST https://api.reallyquickemails.com/domains/register \
  -H "Authorization: Bearer sk_proj_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{ "domain": "cliente.com" }'

Para que publique el DNS de un click, usa Domain Connect: GET /domains/cliente.com/domain-connect devuelve una URL firmada que crea los registros en su proveedor.

Registra su reply domain (opcional)

Para que las respuestas lleguen a nombre@reply.cliente.com en vez de a una dirección con token:

curl -X POST https://api.reallyquickemails.com/domains/reply \
  -H "Authorization: Bearer sk_proj_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{ "domain": "cliente.com" }'

Puedes registrar uno por cada cliente en el mismo proyecto. Cada envío resuelve el reply domain que corresponde al dominio del remitente. Para verificar uno concreto, pasa domain en el body de POST /domains/reply/verify.

Espera la verificación

Cuando tu cliente publique el DNS, recibes el webhook domain.verified — no hace falta pollear. Ver Webhooks.

Envía en su nombre

Con la misma API key, envía transaccional o en lote usando su dominio como remitente.

Depura y mide por cliente

Los envíos de un cliente concreto:

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

Y sus métricas agregadas, con entregas, rebotes, aperturas y clicks:

curl "https://api.reallyquickemails.com/v1/domain-stats" \
  -H "Authorization: Bearer sk_proj_xxxxxxxxxxxx"

Ver Activity y domain-stats.

Mira hard_bounce_rate, no el total de rebotes. Los proveedores calculan el umbral de suspensión (~5%) sobre los rebotes permanentes; los temporales no cuentan. Un dominio puede mostrar 12% de rebote total y estar por debajo del 1% de hard bounce.Y pide a cada cliente que publique el DKIM de su propio dominio: es lo que hace que su reputación de envío sea suya y no se mezcle con la de los demás.

Con un agente de IA (MCP)

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

Ver MCP · modo partner.

Referencia

Dominios — alta, verificación, salud, reply domain y tracking domain.
Activity — ?sender_domain= y /v1/domain-stats.
API pública — envío.
Webhooks — domain.verified y eventos de email.
Partner / Provisioning — referencia completa de /v1/partner/*: alta, dominios, remitentes, API key y códigos de error.

Guías

La app

Conceptos

API Reference

Empieza acá

Configura un cliente que ya existe

Si tu cliente no controla su DNS

Revisa la salud de tus clientes

Alternativa — varios clientes en un proyecto

Con un agente de IA (MCP)

Referencia

​Empieza acá

​Configura un cliente que ya existe

​Si tu cliente no controla su DNS

​Revisa la salud de tus clientes

​Alternativa — varios clientes en un proyecto

​Con un agente de IA (MCP)

​Referencia

Empieza acá

Configura un cliente que ya existe

Si tu cliente no controla su DNS

Revisa la salud de tus clientes

Alternativa — varios clientes en un proyecto

Con un agente de IA (MCP)

Referencia