Programar un webhook
Haga que una URL suya reciba una llamada según un horario cron, para un informe nocturno, una revisión de renovaciones o calentar una caché, sin mantener un servidor o un contenedor encendido solo para vigilar el reloj. Paga por uso, sin suscripción.
Ejecutar una tarea recurrente solía significar mantener un servidor o un contenedor vivo solo para vigilar un reloj.
Una tarea recurrente sin servidor propio
Ejecutar algo con horario solía obligar a mantener un proceso vivo en algún lugar solo para mirar el reloj: un cron en una máquina virtual, un contenedor programado o una función sin servidor con su propia configuración de horarios. Cada opción necesita vigilancia, tiene que sobrevivir a los reinicios y exige que alguien note cuándo deja de dispararse en silencio. Para una sola tarea recurrente, eso es desproporcionado. Aquí usted registra una URL junto con una expresión cron y el contenido que se envía. El horario queda guardado y su URL recibe la llamada automáticamente en cada momento que coincide, desde nuestra infraestructura, sin consultas periódicas ni conexiones permanentes por su parte.
La sintaxis cron de siempre y cuándo conviene
El formato cron nació con la herramienta cron original de Unix en los años 1970, para que los administradores pudieran anotar tareas recurrentes como simples líneas de texto. Décadas después sigue siendo el idioma común de los horarios recurrentes en casi todas partes, así que las expresiones que ya tiene, y la costumbre de escribirlas, le sirven tal cual. En lugar de un proceso en segundo plano cuya única tarea es despertarse, mirar la hora y enviar una petición, esa lógica pasa al horario que usted registra. Encaja con un informe nocturno, una revisión de renovaciones de suscripción o el calentamiento de una caché, tanto en equipos pequeños como en proyectos personales.
El costo de mantener su propio programador
Un equipo pequeño construyendo un producto SaaS, una persona desarrollando un proyecto personal, o un equipo de herramientas internas en una empresa más grande, todos terminan necesitando que algo suceda en un horario: un reporte nocturno, una revisión de renovaciones de suscripción, un precalentamiento de caché, y la respuesta tradicional es un proceso persistente en algún lugar: un demonio cron en una máquina virtual, un contenedor programado, una función sin servidor con su propia configuración de programación.
Cada una de esas opciones necesita monitoreo, necesita sobrevivir reinicios, y necesita que alguien note cuando deja de dispararse en silencio. Para una sola tarea recurrente, esa infraestructura es desproporcionada frente al trabajo que hace.
Qué puede hacer con ella
Automatización de proyectos personales
Agregue un disparador programado a una aplicación pequeña sin aprovisionar un servidor solo para correr una tarea recurrente.
Preguntas frecuentes
¿Hay un nivel gratuito para esta api?
No hay capa gratuita: las capas gratis se abusan y ralentizan a todos. Sin suscripción, sin tokens ni créditos inventados, y una tarea fallida no se cobra.
¿Puedo usar cualquier expresión cron estándar?
Sí, acepta sintaxis cron estándar, así que las expresiones que ya usa en otros programadores generalmente se pueden reutilizar directamente.
¿Necesito mantener un servidor encendido?
No. El horario queda guardado y su URL recibe la llamada desde nuestro lado en cada momento que coincide, así que usted solo mantiene la dirección que hace el trabajo, sin consultas periódicas ni conexiones abiertas.
¿Qué tengo que enviar para programar un horario?
Tres cosas: una expresión cron que indica cuándo, la URL a la que llamar y el contenido que se envía en cada ejecución. Una vez registrado, el horario queda guardado y usted recibe la confirmación de que está activo.
¿Por qué no usar cron en mi propio servidor?
Puede hacerlo, pero un cron en una máquina virtual, un contenedor programado o una función con su propio planificador necesitan vigilancia, deben sobrevivir a los reinicios y alguien tiene que notar cuándo dejan de funcionar sin avisar. Para una sola tarea recurrente es demasiada infraestructura.
Herramientas relacionadas
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
Un POST autenticado crea la tarea; el resultado llega por webhook o enlace firmado. Esta capacidad está disponible actualmente mediante la API, no como herramienta interactiva en la Web.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/dev/cron-webhook \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"url":"https://example.com/hook","cron":"0 9 * * 1"}'const res = await fetch("https://api.kit.forhosting.com/dev/cron-webhook", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"url": "https://example.com/hook",
"cron": "0 9 * * 1"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/dev/cron-webhook",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"url": "https://example.com/hook",
"cron": "0 9 * * 1"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/dev/cron-webhook", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"url":"https://example.com/hook","cron":"0 9 * * 1"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"url":"https://example.com/hook","cron":"0 9 * * 1"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/dev/cron-webhook", 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
{
"url": "https://example.com/hook",
"cron": "0 9 * * 1"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "dev.cron_webhook",
"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. |
Notas técnicas
Esta API de tareas programadas cron le permite registrar un webhook contra una expresión cron y que se llame según ese horario desde nuestra infraestructura en vez de la suya, así lo único que mantiene es el endpoint que hace el trabajo real.
Registrar un horario en una sola llamada
POST /dev/cron-webhook acepta una expresión cron y una URL de webhook destino, junto con el contenido a enviar en cada disparo; una vez registrado, el horario se guarda y el webhook se dispara automáticamente en cada momento correspondiente, sin sondeo ni conexión persistente de su lado. La solicitud de registro en sí se pone en cola de forma asíncrona y devuelve un task_id que confirma que el horario está activo, con confirmación entregada por webhook firmado o por un enlace firmado válido por 24 horas.
Una sintaxis cron que sobrevivió a las razones por las que se inventó
El formato de expresión cron se construyó para la utilidad cron original de Unix en los años setenta, para que los administradores listaran tareas recurrentes en una tabla de texto plano sin un programador gráfico. Décadas después, esa misma sintaxis compacta sigue siendo el lenguaje común para describir horarios recurrentes en casi cualquier plataforma, razón por la cual construir sobre ella, en vez de inventar una sintaxis de programación nueva, significa que las expresiones cron existentes, y el conocimiento de cómo escribirlas, se trasladan directamente a este endpoint.
Qué reemplaza en un sistema real
En vez de un proceso en segundo plano cuyo único trabajo es despertar, revisar la hora y disparar una solicitud HTTP, esa lógica se traslada por completo al registro del horario, y su aplicación solo necesita exponer un endpoint que reciba el webhook y haga el trabajo real cuando se le llame. Esto encaja de forma limpia con el resto de un flujo de tareas: un webhook disparado según un horario puede a su vez iniciar otras tareas asíncronas. A $0.002 por solicitud, el costo de mantener un disparador programado es insignificante frente a la infraestructura que reemplaza.
Acceso, confiabilidad y estado actual
Una entrega fallida del disparo se reintenta automáticamente hasta tres veces antes de reportar un error claro, y un intento fallido nunca se cobra. Usar el endpoint requiere saldo prepago; sin saldo, la solicitud de registro devuelve HTTP 402 en vez de un horario que nunca se dispara en silencio. El endpoint está activo ahora, y los datos del contenido asociados a cada horario se manejan bajo las mismas reglas de retención y borrado que el resto de la API, nunca se usan para entrenamiento.
Casos de integración
Generación de reportes nocturnos
Dispare un webhook cada noche a una hora fija para iniciar un trabajo de reportes sin mantener un proceso programador corriendo.
Revisiones de suscripción y facturación
Dispare un webhook recurrente el primero de cada mes para revisar próximas renovaciones, sin un proceso dedicado en segundo plano.
Precalentamiento de caché y datos
Programe un webhook cada pocas horas para refrescar una caché o precalcular un conjunto de datos antes de un pico de tráfico.
Preguntas técnicas
¿Cómo funciona esta api de tareas programadas cron?
Envía una expresión cron y una URL de webhook a POST /dev/cron-webhook, y el webhook se llama automáticamente según ese horario a partir de entonces.
¿Necesito mantener un servidor corriendo para que funcione el horario?
No, el horario se almacena y dispara desde nuestra infraestructura; de su lado solo necesita exponer el endpoint que recibe la llamada del webhook.
¿Cuánto cuesta la api de cron con webhook?
Cuesta un plano $0.002 por solicitud para registrar y administrar un horario.
¿Qué pasa si mi endpoint de webhook no responde?
Una entrega fallida se reintenta automáticamente hasta tres veces antes de reportar un error claro, y un intento fallido nunca se cobra.
¿Está activa la api de cron con webhook ahora mismo?
Sí, está activa y aceptando registros de horarios.
¿Puedo programar varios webhooks a la vez?
Sí, registre un horario por solicitud; cada uno es independiente, así puede correr varios disparadores recurrentes en paralelo.