Programar peticiones HTTP

Una petición HTTP recurrente que lanza el servidor de tu empresa: la sección HTTP CRON, el intervalo dentro y fuera de horario, la llamada, el resultado que guarda y los avisos por correo.

Una petición HTTP programada es un registro de la sección HTTP CRON. El servidor de tu empresa llama a su URL cada cierto número de segundos, dentro del horario y los días que le marques. Guarda el resultado de la última llamada. Sirve para lanzar un escenario de n8n, Make o Zapier a un ritmo fijo, pedir a tu API que sincronice, o comprobar un servicio. Cuando lo que quieres es reaccionar a un cambio, no a un reloj, usa un webhook saliente.

Antes de empezar

La URL de destino, que empieza por http o https. Sin ese prefijo el servidor ignora el registro.
Si el destino pide autenticación, su token Bearer.
Una clave API con permiso sobre la sección HTTP CRON, identificador 2ccf4f1a-ce66-43bd-a49d-b5353343ec13. La sección no tiene pantalla propia en Play: sus registros se crean y se editan por la API o con el SDK, como los de cualquier otra sección. Ver Plataforma y sistema.

Los campos

Los nombres de columna son los de la sección de fábrica; compruébalos en Desarrollo → Esquema (Esquema).

Campo	Columna	Qué es
Nombre	`nombre`	El texto con el que identificas la petición. Aparece en los avisos por correo.
URL	`pr_40786361020`	La dirección completa. Obligatoria.
Método	`pr_40786361019`	`1` para `GET`, `2` para `POST`, `3` para `PUT`. Otro valor se ejecuta como `GET`.
Bearer	`pr_40786361018`	Opcional. El servidor lo envía en la cabecera `Authorization: Bearer <token>`.
Activo	`pr_60786362`	`1` para que se ejecute. Solo se leen los registros activos y no eliminados.
Intervalo	`pr_40786361032`	Cada cuántos segundos se lanza dentro del horario.
Intervalo fuera de horario	`pr_40786361031`	Cada cuánto se lanza fuera del horario y los días no marcados.
Lunes a Domingo	`pr_40786361026`, `pr_40786361027`, `pr_40786361025`, `pr_40786361024`, `pr_40786361030`, `pr_40786361023`, `pr_40786361022`	`1` en los días con horario.
Hora inicio, Hora fin	`pr_40786361028`, `pr_40786361029`	La franja "dentro de horario", como `HH:mm:ss`. Las dos vacías cuentan como el día entero.
Última ejecución, Último código de estado, Última duración	`pr_50786366`, `pr_10786781002`, `pr_10786781001`	Los escribe el servidor tras cada llamada.

Los campos de programación llevan un autorrellenado fijo en el formulario de la sección: todos los días, de 07:00 a 23:00, cada 30 segundos dentro de horario y cada 300 fuera, método GET, activo. Escribe el registro con scripts=false para que esos valores fijos no sobrescriban los tuyos.

Crear la petición

Prepara el destino

Deja lista la URL y, si hace falta, el token. El destino recibe la llamada sin cuerpo: si necesita datos, ponlos en la propia URL como parámetros.

Crea el registro

Un POST /api/writeoperations a la sección HTTP CRON con scripts=false. Este ejemplo llama cada 5 minutos de lunes a viernes de 08:00 a 20:00, y cada hora el resto del tiempo:

curl -X POST "https://<clave-de-conexion>.dinaup.io/api/writeoperations?sectionId=2ccf4f1a-ce66-43bd-a49d-b5353343ec13&FieldPrimary=id&scripts=false" \
  -H "Authorization: Bearer <token>" \
  -H "Content-Type: application/json" \
  -d "{\"id\": \"\", \"nombre\": \"Sincronizar pedidos\", \"pr_40786361020\": \"https://tu-servidor.com/sync\", \"pr_40786361019\": \"2\", \"pr_40786361018\": \"<token-del-destino>\", \"pr_60786362\": \"1\", \"pr_40786361032\": \"300\", \"pr_40786361031\": \"3600\", \"pr_40786361026\": \"1\", \"pr_40786361027\": \"1\", \"pr_40786361025\": \"1\", \"pr_40786361024\": \"1\", \"pr_40786361030\": \"1\", \"pr_40786361023\": \"0\", \"pr_40786361022\": \"0\", \"pr_40786361028\": \"08:00:00\", \"pr_40786361029\": \"20:00:00\"}"

El servidor relee la lista de peticiones activas en cuanto cambia la sección. La primera llamada sale en el siguiente barrido, unos 10 segundos después.

Comprueba el resultado

Lee el registro por la API o con un informe sobre la sección. Último código de estado trae el código HTTP que respondió el destino; Última duración, los milisegundos; Última ejecución, la fecha en UTC.

Cada cuánto se ejecuta

El servidor barre las peticiones activas cada 10 segundos, con hasta 100 registros por barrido, y decide para cada una si le toca:

Situación	Intervalo que aplica
Día marcado y hora dentro de la franja	Intervalo.
Día marcado y hora fuera de la franja	Intervalo fuera de horario.
Día sin marcar	Intervalo fuera de horario.
Intervalo `0`	Ese tramo no se ejecuta. Con los dos intervalos a `0` la petición no sale nunca.
Intervalo menor que 10	Se ejecuta cada 10 segundos.

La hora es la hora local de tu empresa. Una petición que nunca se ha ejecutado sale en el primer barrido; a partir de ahí, cuando desde la última ejecución han pasado tantos segundos como marca el intervalo.

La llamada

Detalle	Valor
Método	`GET`, `POST` o `PUT`, según el campo Método.
Cuerpo	Vacío. `POST` y `PUT` salen sin contenido.
Cabeceras	Solo `Authorization: Bearer <token>` si el campo Bearer está relleno.
Tiempo de espera	30 segundos.
Solapamiento	Mientras una llamada está en curso no se lanza otra de la misma petición.

El resultado y los avisos

Tras cada llamada el servidor guarda tres datos en el registro:

Campo	Qué ves
Última ejecución	Fecha y hora de la llamada, en UTC.
Último código de estado	El código HTTP del destino, o `-1` si no respondió a tiempo o falló la conexión.
Última duración	Lo que tardó, en milisegundos.

Un código fuera de 2xx cuenta como fallo. Tras 5 fallos seguidos, o 15 minutos fallando, Dinaup envía un correo a tu empresa con el asunto Tu tarea programada '<nombre>' ha dejado de funcionar. Cuando el destino vuelve a responder 2xx, envía Tu tarea programada '<nombre>' vuelve a funcionar con el tiempo que estuvo caída. Una sola respuesta buena reinicia la cuenta de fallos.

Código	Qué revisar
`2xx`	Nada: funciona.
`401` o `403`	El token del campo Bearer.
`404`	La URL.
`-1`	El destino no responde en 30 segundos o no acepta la conexión.

Aunque tu empresa tenga varios servidores, cada petición sale una sola vez: las peticiones programadas solo las lanza el servidor activo.

Cron o webhook

Necesitas	Usa
Que Dinaup te llame cada X minutos, pase lo que pase	Petición HTTP programada.
Enterarte de que un registro se creó o cambió	Webhook saliente.
Que tu sistema pregunte a Dinaup cada X minutos	Tu propio programador contra la API REST.

Relacionado

Zapier, Make y n8n: el destino habitual de una petición programada.
Webhooks salientes: el aviso por evento.

En esta página