Dinaup DocsProgramar peticiones HTTP
Crea una petición programada: define destino, método, autenticación Bearer, frecuencia y franja horaria, y revisa el resultado de cada ejecución
El servidor de Dinaup puede llamar solo a una URL cada cierto tiempo, sin que tú hagas nada. Sirve para disparar flujos externos (n8n, Make, Zapier), sincronizar con otra API tuya o hacer comprobaciones periódicas.
Para la visión general de lo que corre en segundo plano, mira → Automatizaciones del servidor.
Antes de empezar
Necesitas tres cosas:
- Acceso a la sección de peticiones HTTP programadas.
- La URL de destino ya lista.
- Si el destino requiere autenticación, el token Bearer a mano.
Crear la petición
Abre la sección de peticiones HTTP programadas
Crea un nuevo registro en la sección de peticiones HTTP programadas. En el sistema, la plantilla se llama HTTP CRON.
¿No encuentras la sección? La habilita tu administrador. Suele vivir en el módulo de desarrollo. Si no aparece, pide acceso a quien gestiona tu cuenta.
Ponle un Nombre descriptivo para identificarlo en la lista.
Define destino y método
Rellena la dirección y cómo se llama:
| Campo | Qué pones |
|---|---|
| URL | La dirección completa. Debe empezar por http o https, si no, el servidor la ignora. |
| Método | GET, POST o PUT. |
El cron solo dispara la URL: no envía cuerpo ni cabeceras propias. POST y PUT salen con cuerpo vacío. Si el destino necesita datos, mételos en la propia URL como parámetros.
Autenticación (opcional)
Si el destino pide autenticación, rellena el campo Bearer con el token. El servidor añade la cabecera Authorization: Bearer <token> a cada llamada.
Si lo dejas vacío, la petición sale sin autenticación. Bearer es el único método soportado: no hay Basic ni cabeceras personalizadas.
Frecuencia, días y horario
Aquí controlas cada cuánto se dispara y cuándo:
| Campo | Qué controla |
|---|---|
| Intervalo en segundos | Cada cuánto se dispara dentro del horario. |
| Intervalo fuera de horario | Otro ritmo para fuera de la franja. Ej.: cada 60 s de día, cada 600 s de noche. |
| Lunes a Domingo | Días activos. Un día sin marcar usa el intervalo de fuera de horario. |
| Hora inicio y Hora fin | Definen la franja "dentro de horario". |
Si dejas Hora inicio u Hora fin vacías, ese día cuenta como dentro de horario las 24 horas. El reloj usa la zona horaria configurada en tu cuenta.
El intervalo mínimo real es 10 segundos. Si pones menos, el servidor lo sube a 10. Un intervalo de 0 o menos hace que la petición no se ejecute.
Activa y guarda
Marca la casilla Activo y guarda. El servidor solo considera los crons activos.
Empieza a tenerlo en cuenta casi de inmediato. La primera ejecución ocurre en cuanto le toca por su horario e intervalo.
Revisa el resultado de cada ejecución
Tras cada llamada, el servidor guarda tres datos en el propio registro:
| Campo | Qué ves |
|---|---|
| Última ejecución | Fecha y hora de la última llamada (en UTC). |
| Último código de estado | El código HTTP real: 200, 404, 500... |
| Última duración | Cuánto tardó, en milisegundos. |
Úsalos para diagnosticar:
| Código | Qué significa |
|---|---|
2xx | Todo correcto. |
401 / 403 | Revisa el Bearer. |
-1 | Error de red o timeout: el destino no responde. |
Cada llamada tiene un límite de 30 segundos. Si lo supera, se registra como -1.
Una sola ejecución con varios servidores
Aunque tu cuenta tenga varios servidores, cada petición se dispara una sola vez, no se duplica. El detalle está en → Automatizaciones del servidor.
Relacionado
- → Automatizaciones del servidor — todo lo que Dinaup ejecuta en segundo plano.
- → Zapier, Make y n8n — el destino típico de un cron saliente.
- → Webhooks salientes — la alternativa: aquí tú preguntas cada X; con un webhook, Dinaup te avisa cuando algo cambia.
- → Conectar una integración — pasos generales para enlazar Dinaup con otra herramienta.