Programar un email
POST /notify/email-scheduled encola un mensaje para un momento futuro específico en lugar de enviarlo ahora, y le entrega un task_id que puede usar para cancelarlo en cualquier momento antes de que llegue esa hora. Reemplaza el pequeño cron job o el worker de cola con retraso que los equipos suelen construir solo para retener un mensaje hasta el momento correcto.
La parte del correo que no es sobre enviar, sino sobre el momento exacto
La mayoría de los problemas de correo tienen que ver con el contenido y la entregabilidad; este es puramente sobre el momento. Un aviso de vencimiento de prueba enviado el día antes de la renovación, un recordatorio de una cita para mañana por la mañana, un mensaje de reactivación exactamente siete días después del registro: ninguno de estos necesita enviarse ahora mismo, y enviarlo ahora mismo sería, de hecho, un error. Este endpoint existe para que 'envía esto, pero después' sea una sola llamada a la API en lugar de un sistema de programación que mantienes usted mismo.
Qué pasa entre la llamada y el envío
Envía el mensaje junto con una hora objetivo de envío, y la tarea queda en cola hasta ese momento en nuestra red global, punto en el cual sale exactamente como un envío normal: mismo intento de entrega, mismo comportamiento de reintento, mismo reporte. El task_id que recibe al enviarlo es su forma de identificar el mensaje mientras está pendiente: representa una tarea real y direccionable, no una solicitud de la que perdió el rastro.
La cancelación es la función que más importa
Un envío programado que no se puede cancelar es apenas más útil que un cron job, porque en el momento en que cambian las circunstancias —se extiende la prueba, se mueve la cita, el cliente cancela su suscripción— necesita retirar el mensaje antes de que salga de todos modos, con la vergüenza que eso implica. Llamar a la operación de cancelación con el task_id antes de la hora de envío lo retira de la cola de forma limpia, y como una tarea cancelada nunca se envía, tampoco se cobra.
Por qué esto es mejor que construir su propia lógica de retraso
Construir envíos con retraso por cuenta propia suele significar una fila en una base de datos con una marca de tiempo futura, un proceso que la revisa periódicamente, y la esperanza de que ese proceso no se caiga entre despliegues. Es infraestructura que la mayoría de los equipos no quiere mantener solo para algo tan pequeño como 'envía esto mañana a las 9am'. Este endpoint absorbe esa infraestructura por completo: la programación, el disparo confiable y la lógica de reintento viven de nuestro lado.
Su lugar dentro de un flujo más amplio
Los envíos programados combinan de forma natural con otras automatizaciones: un registro dispara una cadena de correos de onboarding espaciados por días, el inicio de una prueba programa su propio aviso de vencimiento en el momento de crearse, una reserva programa su propio recordatorio. Cada uno de estos casos es una sola llamada en el instante del evento que lo dispara, no un trabajo recurrente vigilando un calendario.
Qué puede hacer con ella
Recordatorios de vencimiento de prueba
En el momento en que empieza una prueba, su aviso de vencimiento se programa para tres días antes de que termine, y se cancela automáticamente si el cliente actualiza su plan antes.
Recordatorios de citas
Una reserva programa un correo recordatorio para la noche anterior a la cita, cancelado al instante si la cita se reprograma o se cancela.
Secuencias de onboarding por goteo
Un evento de registro programa una serie de correos con consejos espaciados por unos días, cada uno como una tarea programada independiente que el usuario puede evitar cancelando su suscripción antes de que se dispare.
Campañas ajustadas por zona horaria
Un envío se programa para las 9am en la hora local del destinatario en lugar de dispararse de inmediato sin importar cuándo lo vaya a ver realmente.
Preguntas frecuentes
¿Con cuánta anticipación puedo programar un correo?
Indica la hora objetivo de envío al enviar la tarea; mientras sea un momento futuro válido, el mensaje queda en cola hasta entonces.
¿Puedo cancelar un correo programado?
Sí: llama a la operación de cancelación con el task_id en cualquier momento antes de la hora programada de envío, y se retira de la cola sin llegar a enviarse ni cobrarse.
¿Cuánto cuesta programar un envío?
$0.002 por solicitud más $0.0035 por correo realmente enviado; una tarea cancelada o fallida nunca se cobra.
¿Hay una capa gratuita para probar la programación?
No hay capa gratuita: las capas gratis se abusan y ralentizan a todos. El acceso funciona con un saldo prepago de ForHosting KIT: se recarga desde $10.00 (no caduca) y cada solicitud se cobra a su precio publicado, así que una llamada sin saldo devuelve HTTP 402. Sin suscripción, sin tokens ni créditos inventados, y una tarea fallida no se cobra.
¿Cómo sé cuándo se envió realmente el correo?
En la hora programada, la entrega procede exactamente como un envío normal, y el resultado se reporta mediante un webhook firmado o un enlace firmado válido por 24 horas.
¿Puedo reprogramar un correo en vez de cancelarlo?
El patrón confiable es cancelar la tarea pendiente y enviar una nueva con la hora de envío actualizada.
¿Qué pasa si la hora programada ya pasó?
Una solicitud con una hora de envío en el pasado se rechaza con un error claro en lugar de enviarse de inmediato o descartarse en silencio.
¿Esto reemplaza un cron job en mi servidor?
Para la programación por mensaje, sí: el endpoint maneja el retraso, el disparo y la lógica de reintento, así que no necesita un proceso de sondeo ni un worker de cola con retraso propio.
Para desarrolladores — acceso por API
Todo lo de esta página está disponible por programación. Esta sección es para equipos que quieren integrarlo en sus sistemas; el resto puede usar la herramienta de arriba sin más.
Endpoint de API
¿Prefiere automatizarlo? Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. La misma capacidad también se ejecuta aquí en la web, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/notify/email-scheduled \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"input":"…"}'const res = await fetch("https://api.kit.forhosting.com/notify/email-scheduled", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"input": "…"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/notify/email-scheduled",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"input": "…"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/notify/email-scheduled", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"input":"…"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"input":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/notify/email-scheduled", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Ejemplo de solicitud
{
"input": "…"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "notify.email_scheduled",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}La API es asíncrona: la llamada devuelve un task_id al instante y el resultado llega por webhook. El polling está limitado a 1 req/s por tarea.
Precio
Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.
Errores
| HTTP | Código | Significado |
|---|---|---|
401 | unauthorized | API key ausente o inválida. |
402 | insufficient_balance | El saldo no cubre el precio de la tarea. |
404 | unknown_type | El tipo de tarea no existe. |
429 | rate_limited | Demasiadas peticiones. Use el webhook en vez de sondear. |