Construir

API para enviar correo electrónico en nombre del usuario

API de correo electrónico

¿Qué significa "Enviar en nombre de" en la API de correo electrónico?

Enviar correos electrónicos en nombre de un usuario significa que tu aplicación envía mensajes directamente desde el buzón del propio usuario, no desde un remitente transaccional compartido. El destinatario ve la dirección de correo electrónico real del usuario en el campo "De". Esta es la base de cualquier producto SaaS que maneje el correo electrónico para sus usuarios.

Qué aprenderás

Cómo las concesiones de OAuth 2.0 envían permisos
Compatibilidad con Gmail, Outlook e IMAP
APIs de correo electrónico en nombre de vs. de transacciones
Enviando a través de la API unificada de Unipile
Casos de uso de CRM, asistente de IA y soporte
Cumplimiento legal y permisos de usuario
Prueba la API de correo electrónico de Unipile Lea la documentación
Enviado desde el buzón del usuario Remitente real
API de Correo Electrónico Unipile
Enviar en nombre de POST
POST /api/v1/emails
200 OK
GET /api/v1/correos/{id}
200 OK
GET /api/v1/cuentas/{id}
200 OK
carga útil JSON
{ "account_id": "usuario_abc123", "a": [{ "identificador": "prospect@acme.com" }], "Asunto": "Seguimiento", "cuerpo": "Hola Sarah..." }
Seguro con OAuth 2.0 El usuario otorga permiso
¿Integración de correo electrónico?

Lee nuestro Guía completa de la API de correo electrónico - Flujos OAuth, sincronización, envío y comparación de proveedores.

Por qué los productos SaaS necesitan envío de correos electrónicos "en nombre de"

La mayoría de los productos SaaS que interactúan con el correo electrónico eventualmente se enfrentan al mismo requisito: el usuario quiere que los mensajes provengan de su propia dirección, no de un dominio genérico de la plataforma. Ya sea un CRM, un asistente de escritura de IA o una herramienta de soporte, en el momento en que tu producto envía correos electrónicos para los usuarios, necesitas el envío en nombre de ellos. Aquí te explicamos por qué es importante y cómo los tres casos de uso principales se mapean a la API.

Caso práctico de CRM

Los representantes de ventas envían desde su Gmail u Outlook real

En un contexto de CRM, el vendedor es quien construye la relación. Si tu plataforma envía seguimientos desde noreply@yourcrm.com, la entregabilidad disminuye y el prospecto se confunde. Con el envío en nombre de, tu CRM llama a la API de Unipile utilizando la cuenta vinculada del vendedor. Cada correo electrónico llega a la bandeja de entrada del prospecto mostrando la dirección real del representante.

Los hilos de correo electrónico permanecen en la carpeta de enviados del representante, manteniendo el historial en un solo lugar
Las respuestas llegan a la bandeja de entrada del representante para una continuidad de conversación natural.
La reputación del remitente está ligada al dominio del representante, no a un dominio de plataforma compartida.
Caso de uso del asistente de IA

La IA redacta y envía desde el buzón del usuario

Los asistentes de correo electrónico de IA, ya sea que redacten respuestas automáticamente, programen seguimientos o resuman hilos, necesitan acceso de escritura al buzón del usuario. Sin el envío "en nombre de", la IA solo puede sugerir; no puede ejecutar. Con una cuenta vinculada a través de la API de Unipile, su asistente puede enviar el mensaje aprobado directamente desde Gmail u Outlook del usuario con una sola llamada API.

Borrador aprobado: una llamada a la API lo envía desde la dirección real del usuario
Funciona si el usuario utiliza Gmail, Outlook o cualquier proveedor IMAP
Admite subprocesos a través del parámetro `reply_to` para mantener las conversaciones intactas.
Caso de uso de la herramienta de soporte

Los agentes de soporte responden desde una bandeja de entrada de soporte compartida

Las plataformas de atención al cliente a menudo enrutan las solicitudes a través de una bandeja de entrada compartida como support@company.com. Esa bandeja de entrada es en sí misma un buzón de correo; debe vincularse como una cuenta. Con Unipile, tu plataforma puede conectar ese buzón compartido de Outlook o IMAP, permitiendo que cualquier agente envíe respuestas que parezcan provenir directamente de la dirección oficial de soporte, con el contexto completo del hilo conservado.

Bandeja de entrada compartida vinculada una vez, accesible para todos los agentes autorizados
Las respuestas siempre muestran el dominio de la empresa correcto en el campo De
Archivos adjuntos, CC y CCO admitidos a través del mismo punto final unificado
Mejor entregabilidad
Los correos electrónicos enviados desde el dominio del usuario pasan las comprobaciones SPF y DKIM asociadas a su cuenta, no a un remitente compartido.
Acceso protegido con OAuth
Los usuarios otorgan permiso a través del flujo OAuth de su proveedor. No se almacenan contraseñas, se puede revocar completamente en cualquier momento.
Una API unificada
Lo mismo POST /api/v1/correos el endpoint maneja cuentas de Gmail, Outlook y IMAP.
Mayor rapidez de comercialización
Omite la creación de integraciones separadas para Gmail, Outlook e IMAP. Unipile normaliza los tres detrás de una única interfaz.
La clave está en: tus usuarios ya tienen direcciones de correo electrónico en las que sus contactos confían. El envío en nombre de permite que tu SaaS aproveche esa confianza sin pedirle a nadie que cambie de proveedor o cree una nueva bandeja de entrada. Para obtener una visión más amplia de cómo funcionan las API de correo electrónico, consulta Guía de la API de correo electrónico.
Empieza a construir gratis

Cómo funciona la API de correo electrónico "On-Behalf" (Flujo de OAuth 2.0)

Enviar correos electrónicos en nombre de un usuario requiere tres cosas: el consentimiento del usuario, un token de acceso válido y una llamada de envío a través de la infraestructura del proveedor. Así es como funciona ese flujo en la práctica y cómo Unipile lo abstrae en una única API unificada. Para una referencia técnica más amplia sobre puntos finales de envío, parámetros y diferencias entre proveedores, consulte nuestra guía completa. Guía de la API para enviar correos electrónicos.

1

El usuario otorga permiso OAuth

El usuario hace clic en "Conectar tu correo" dentro de tu producto SaaS. Unipile lo redirige a la pantalla de consentimiento OAuth de su proveedor: Google para usuarios de Gmail, Microsoft para usuarios de Outlook y Microsoft 365. El usuario inicia sesión y aprueba los ámbitos solicitados, que incluyen la capacidad de enviar correos electrónicos en su nombre. Nunca se comparte ninguna contraseña con tu aplicación.

Para los proveedores IMAP, el usuario introduce su contraseña específica de la aplicación o sus credenciales IMAP directamente en un formulario alojado por Unipile. Unipile almacena las credenciales cifradas y gestiona la reconexión automáticamente.
2

Tu aplicación recibe un ID de cuenta vinculado

Una vez que el usuario completa el flujo de OAuth, Unipile almacena de forma segura el token de acceso y devuelve un account_id a tu aplicación. Este es un identificador estable para el buzón conectado del usuario. Almacenas este ID en tu base de datos junto con el registro del usuario. Todas las operaciones de correo electrónico subsiguientes para este usuario hacen referencia a este account_id; nunca tocas el token OAuth sin procesar.

Unipile maneja la renovación de tokens automáticamente. Si un token de Gmail o Outlook expira, Unipile lo renueva en segundo plano para que tus llamadas de envío nunca fallen debido a credenciales caducadas.
3

Enviar a través de la infraestructura del proveedor

Cuando su aplicación necesita enviar un correo electrónico, llama a POST /api/v1/correos con el account_id y el payload del mensaje. Unipile enruta la solicitud a través del proveedor correcto: la API de Gmail para cuentas de Google, la API de Microsoft Graph para cuentas de Outlook y Microsoft 365, y SMTP para cuentas IMAP. El correo electrónico se envía desde el propio buzón del usuario y aparece en su carpeta Enviados.

La misma llamada a la API funciona independientemente del proveedor. Escribes una integración; Unipile la traduce a la API de Gmail, Microsoft Graph o SMTP de forma transparente.

Ejemplos de códigos

Python
Node.js
Python - Enviar correo electrónico en nombre del usuario
import solicita

# account_id recuperado después de que el usuario completa el flujo de OAuth
UNIPILE_DSN = "https://api1.unipile.com:13301"
ACCESS_TOKEN = "TU_TOKEN_DE_ACCESO"
ACCOUNT_ID   = "id_cuenta_de_usuario_de_la_base_de_datos"

carga_útil = {
    "account_id": ID_DE_CUENTA,
    "a": [{
        "nombre_a_mostrar": "Sarah Connor",
        "identificador":   "sarah@acme.com"
    }],
    "Asunto": "Dando seguimiento a nuestra conversación",
    "cuerpo":    "
Hola Sarah, solo para dar seguimiento...
 "
}

respuesta = requests.Correo electrónico:(
    f"{UNIPILE_DSN}/api/v1/correos",
    json=payload,
    encabezados={"Clave API X": ACCESS_TOKEN}
)

print(respuesta.json())  # {"object": "EmailSent", "email_id": "..."}
Node.js - Enviar correo electrónico en nombre del usuario
// account_id recuperado después de que el usuario complete el flujo OAuth
const UNIPILE_DSN = "https://api1.unipile.com:13301";
const ACCESS_TOKEN = "TU_TOKEN_DE_ACCESO";
const ID_DE_CUENTA = "id_cuenta_de_usuario_de_la_base_de_datos";

const carga_útil = {
  account_id: ID_DE_CUENTA,
  a: [{ nombre_mostrador: "Sarah Connor", identificador: "sarah@acme.com" }],
  tema: "Dando seguimiento a nuestra conversación",
  cuerpo:    "
Hola Sarah, solo para dar seguimiento...
 "
};

const response = await fetch(`${UNIPILE_DSN}/api/v1/emails`, {
  método: "PUBLICAR",
  cabeceras: {
    "Clave API X":     TOKEN_DE_ACCESO,
    "Tipo-Contenido": "application/json"
  },
  cuerpo: JSON.stringify(carga útil)
});

const datos = await respuesta.json();
consola.log(datos); // { objeto: "EmailEnviado", email_id: "..." }

API de correo electrónico "On-Behalf" vs. transaccional: La diferencia clave

Estas dos categorías de API de correo electrónico resuelven problemas fundamentalmente diferentes. Mezclarlas es el error más común que cometen los equipos al especificar una integración de correo electrónico. Aquí se comparan en cada dimensión que importa.

Criterios
En nombre de (Unipile)
Transaccional (SendGrid, etc.)
De la dirección
La dirección de correo electrónico real del usuario
El dominio de tu plataforma
Entregabilidad
Reputación SPF/DKIM del usuario
Reputación de IP de envío compartida
Se requiere el consentimiento del usuario
Sí - credenciales de OAuth 2.0 o IMAP
No, la plataforma es dueña del remitente.
Seguimiento de la carpeta Enviados
Aparece en la carpeta de Enviados del usuario
No - infraestructura de envío separada
Enhebrado de respuestas
Continuidad de hilos nativos
Soluciones alternativas manuales para el ID de mensaje
Mejor para
CRM, asistentes de IA, herramientas de soporte, automatización de ventas
Restablecimientos de contraseña, recibos, campañas de marketing, notificaciones
Soporte del proveedor
Gmail, Outlook, IMAP
SMTP agnóstico al proveedor
Cuándo usar cada enfoque
Usa una API "on-behalf" cuando la identidad del remitente sea importante para el destinatario: prospección de ventas, seguimientos personalizados, respuestas de soporte. Usa una API transaccional cuando la plataforma sea el remitente: restablecimientos de contraseñas, facturas, notificaciones del sistema. Muchos productos SaaS necesitan ambas: una API transaccional para correos electrónicos del sistema y una API "on-behalf" para mensajes impulsados por el usuario. Para detalles de implementación específicos de Gmail, consulta Enviar correo electrónico con la API de Gmail guía. Para cuentas de Microsoft, consulta las API de correo electrónico de Outlook guía.

Crea el envío de correo electrónico en nombre de con Unipile

Unipile proporciona una única API unificada que abstrae Gmail, Outlook e IMAP tras una interfaz coherente. Escribes una integración: Unipile se encarga de los flujos de OAuth específicos del proveedor, la actualización de tokens, el enrutamiento SMTP y el manejo de errores para los tres. Aquí tienes lo que está disponible para cada proveedor.

¿Listo para añadir el envío de correos electrónicos en nombre de terceros a tu SaaS?
Prueba gratuita - no se requiere tarjeta de crédito. Comienza a enviar en menos de 30 minutos.
Leer la Guía de la API de correo electrónico
Proveedores subvencionados
Gmail
Google OAuth 2.0
Envía a través de la API de Gmail: compatibilidad completa con hilos
Cuentas de Google Workspace admitidas
Archivos adjuntos, CC, CCO, responder a
Actualización automática de tokens manejada por Unipile
Guía de envío de correos electrónicos con la API de Gmail
Outlook
Microsoft OAuth 2.0
Enviar a través de la API de Microsoft Graph
Cubiertas personales de Outlook y Microsoft 365
Exchange Online totalmente compatible
Archivos adjuntos, CC, CCO, responder a
Guía de la API de correo electrónico de Outlook
IMAP
Recurso universal de último recurso
Envía vía SMTP a cualquier buzón compatible con IMAP
Cubre Yahoo, Fastmail, ProtonMail (puente IMAP) y más
El mismo punto final de API unificado que Gmail y Outlook
Credenciales almacenadas cifradas, nunca expuestas a tu aplicación
Guía de la API IMAP
Cómo empezar en 4 pasos
1 Crear una cuenta de Unipile en dashboard.unipile.com y recupera tu DSN y clave API.
2 Generar un enlace de autenticación alojado para su usuario. Unipile maneja la redirección OAuth a Gmail u Outlook, o muestra el formulario de credenciales IMAP.
3 Almacena el account_id devuelto después de que el usuario completa el flujo. Este es el identificador estable para todas las operaciones futuras en ese buzón.
4 Llamar POST /api/v1/emails con el account_id y la carga útil del mensaje. El correo electrónico se envía desde el buzón del propio usuario, a través de la infraestructura de su proveedor.
Envío de correos electrónicos en nombre de hoy Leer la documentación de la API

API de envío de correo electrónico en nombre del usuario - Preguntas frecuentes

Preguntas frecuentes sobre el envío de correos electrónicos en nombre de con Unipile

Sí, siempre y cuando el usuario otorgue permiso explícitamente. El envío de correos electrónicos en nombre de otros se basa en OAuth 2.0 (para Gmail y Outlook) o en el intercambio explícito de credenciales (para IMAP). En ambos casos, el usuario autoriza conscientemente a tu aplicación a enviar desde su buzón. Este es el mismo mecanismo utilizado por todos los principales clientes de correo electrónico y herramientas de productividad.

Los requisitos clave de cumplimiento son:

  • El usuario debe dar su consentimiento activamente antes de que envíes algo en su nombre
  • Tu política de privacidad debe revelar que accedes y envías desde el buzón del usuario
  • El usuario debe poder revocar el acceso en cualquier momento (revocación de OAuth o desconexión de cuenta)
  • No debes enviar contenido que viole los términos de servicio del proveedor (por ejemplo, spam)

No es legal para enviar desde la dirección de alguien sin su consentimiento. El flujo de vinculación basado en OAuth de Unipile garantiza que siempre tenga la autorización explícita del usuario antes de cualquier operación de envío.

El destinatario ve el dominio propio del usuario en el campo De: no el dominio de tu plataforma. Este es el valor central de enviar en nombre de. Por ejemplo, si un representante de ventas con la dirección john@acme.com ha vinculado su cuenta de Gmail, cada correo electrónico enviado a través de su CRM a través de Unipile mostrará De: john@acme.com.

El correo electrónico se envía a través del proveedor de correo real del usuario (API de Gmail, Microsoft Graph o SMTP), lo que significa:

  • Los registros SPF pasan porque la IP de envío está autorizada por el dominio del usuario.
  • Las firmas DKIM son válidas porque el proveedor firma con la clave de dominio del usuario
  • La alineación DMARC pasa por las mismas razones

Esto es fundamentalmente diferente de una API transaccional donde envías desde una infraestructura compartida y el destinatario ve el dominio de tu plataforma.

Los ámbitos requeridos dependen del proveedor. Unipile maneja la pantalla de consentimiento OAuth automáticamente: sus usuarios verán un diálogo de permisos estándar de Google o Microsoft. Los ámbitos exactos solicitados son:

  • Gmail: el ámbito de la API de Gmail que permite enviar mensajeshttps://mail.google.com/ o el más limitado gmail.enviar ámbito (si solo necesitas acceso de envío)
  • Outlook / Microsoft 365: Microsoft Graph Mail.Enviar alcance, más Mail.ReadWrite si también necesitas leer o sincronizar la bandeja de entrada
  • IMAP: El usuario proporciona su nombre de host IMAP, puerto, nombre de usuario y su contraseña o una contraseña específica de la aplicación (requerida para cuentas con autenticación de dos factores habilitada).

Los usuarios pueden revocar estos permisos en cualquier momento desde la configuración de seguridad de su cuenta de Google o Microsoft, o desconectando la cuenta vinculada dentro de su producto.

Sí. Cualquier buzón de correo que pueda ser autenticado a través de credenciales OAuth o IMAP puede vincularse como una cuenta de Unipile. Esto incluye:

  • Buzones compartidos en Microsoft 365 (ej. support@company.com) - enlazado a través de una cuenta de servicio con los permisos delegados correctos
  • Bandejas de entrada compartidas de Google Workspace y direcciones de grupo con permisos de Enviar como configurados
  • Cualquier alias de correo electrónico que sea administrado por un buzón de correo accesible IMAP

También puedes personalizar la nombre a mostrar en el campo De usando el from parámetro en la carga útil de la API, sin cambiar la dirección de envío subyacente.

Unipile maneja la actualización automática de tokens para cuentas de Gmail y Outlook. Los tokens de acceso OAuth generalmente expiran después de una hora, pero el token de actualización tiene una vida útil larga. Cuando Unipile detecta un token de acceso expirado antes de una operación de envío, solicita uno nuevo de forma silenciosa utilizando el token de actualización almacenado; su aplicación nunca ve que esto suceda y la llamada de envío se completa normalmente.

La única vez que necesitas solicitar al usuario que se reautentique es si tiene acceso revocado manualmente desde su cuenta de Google o Microsoft. Unipile muestra esto como un cambio de estado de cuenta que puede detectar a través de webhook o consultando el punto final de la cuenta.

¿Aún tiene preguntas? Nuestro equipo está aquí para ayudarle.

Hable con un experto
es_ESES
en_USEN fr_FRFR de_DEDE it_ITIT pt_BRBR nl_NLNL pl_PLPL tr_TRTR es_ESES