Analice cabeceras de límite y calcule el reinicio
Un límite de 100 con 42 restantes y un reinicio de 60 a las 12:00 UTC significa que podrá volver a enviar solicitudes a las 12:01, dentro de 60 segundos. Pegue los tres valores y la hora de recepción para reintentar con seguridad. Gratis en su navegador.
- Gratis
- Funciona en su navegador
- Sin registro
- Sus datos no salen de su equipo
Ejecutar — gratis
Ejemplo resuelto
- Límite
- 100
- Restante
- 42
- Restablecimiento
- 60
- Hora actual
- 2026-07-25T12:00:00Z
- Límite
- 100
- Restante
- 42
- Tipo de restablecimiento
- seconds_offset
- Restablecimiento en tiempo Unix
- 1 784 980 860
Las cabeceras de límite parecen sencillas hasta que cada servicio expresa el reinicio de forma distinta. Este analizador recibe el límite, la cantidad restante, el valor de reinicio y una hora actual explícita; después devuelve valores numéricos normalizados y los segundos completos que faltan para recuperar las solicitudes. Admite marcas Unix en segundos o milisegundos, fechas ISO 8601 UTC estrictas y desplazamientos numéricos breves. Como usted proporciona la hora actual, una misma entrada siempre genera el mismo resultado.
Comprenda cómo se distinguen las marcas y los desplazamientos
Los valores numéricos de reset siguen convenciones habituales. Un valor de al menos mil millones se interpreta como segundos Unix; a partir de cien mil millones se considera milisegundos Unix y se convierte a segundos. Así, 30 o 900 funcionan como demoras, mientras las marcas de época actuales siguen siendo absolutas.
También puede usar una fecha UTC ISO 8601 estricta, como 2026-07-25T12:01:00Z, con milisegundos opcionales. La validación detecta fechas imposibles, horas inválidas, valores ausentes, números negativos y texto ajeno. Un reset ilegible genera un error de entrada, en vez de convertirse silenciosamente en cero y provocar reintentos inmediatos.
Use resultados deterministas en clientes y pruebas
Una política de reintentos debe separar el análisis de las decisiones. Por ejemplo, un desplazamiento de 60 con una hora actual exactamente al mediodía siempre produce una marca un minuto posterior y sesenta segundos restantes. Esta herramienta no infiere cabeceras de proveedores ni elige el retroceso exponencial.
Procesa los valores ya extraídos.
Qué puede hacer con ella
Programe un reintento seguro
Convierta cadenas de cabeceras en una demora de segundos completos antes de devolver el trabajo a una cola.
Diagnostique la limitación del proveedor
Normalice cabeceras capturadas y compare el reinicio con el instante exacto de la respuesta.
Cree pruebas de reintento deterministas
Proporcione una hora fija y verifique cálculos estables sin simular el reloj del sistema.
Preguntas frecuentes
¿Qué formatos de reinicio se aceptan?
Use desplazamientos no negativos en segundos, marcas Unix en segundos o milisegundos, o fechas UTC ISO 8601 estrictas terminadas en Z.
¿La herramienta realiza una solicitud o espera?
No. Solo valida y normaliza sus valores; su aplicación sigue siendo responsable del reintento y el retroceso.
¿Qué ocurre si el momento de reinicio ya pasó?
La espera es cero, nunca negativa. Resulta útil al revisar registros archivados o avisos que llegaron con retraso, porque el resultado indica que ya puede volver a intentarlo sin inventar un tiempo de espera.
¿Por qué tengo que indicar la hora actual?
Para que ningún reloj del sistema cambie la respuesta: los mismos datos dan siempre el mismo resultado. Use el instante en que recibió la respuesta, en segundos o milisegundos Unix o como fecha UTC; nunca se interpreta como un desfase.
¿Qué pasa si las solicitudes restantes superan el límite?
Se rechaza la entrada. El límite y las restantes deben ser números enteros no negativos, y las restantes no pueden ser mayores que el límite. Un reinicio ilegible también da error en lugar de cero, para evitar reintentos inmediatos.
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
¿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, por email y desde Telegram — y pronto también desde nuestra app.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/security/rate-limit-header-parse \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}'const res = await fetch("https://api.kit.forhosting.com/security/rate-limit-header-parse", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/security/rate-limit-header-parse",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/security/rate-limit-header-parse", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"limit":"100","remaining":"42","reset":"60","current_time":"2026-07-25T12:00:00Z"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/security/rate-limit-header-parse", 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
{
"limit": "100",
"remaining": "42",
"reset": "60",
"current_time": "2026-07-25T12:00:00Z"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "security.rate_limit_header_parse",
"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
Normalice las cabeceras antes de programar reintentos
Conserva el texto original de reset, informa si lo interpretó como marca temporal absoluta o desplazamiento en segundos y genera una hora Unix normalizada. Si el reinicio ya pasó, devuelve cero y nunca un número negativo. El resultado sirve para registros, middleware de reintentos, demoras de colas y pruebas sin repetir las mismas reglas en cada integración. Las API suelen publicar un máximo de solicitudes, una cantidad restante y un valor de reinicio, pero el cliente aún debe convertir esas cadenas en una decisión segura. Envíe esos valores como limit, remaining y reset, e indique en current_time el instante en que recibió la respuesta. El analizador verifica que limit y remaining sean enteros no negativos y rechaza una cantidad restante superior al límite. El campo seconds_until_reset se redondea hacia arriba para impedir que usted reintente durante la última fracción del intervalo.
Comprenda cómo se distinguen las marcas y los desplazamientos
Los números menores no negativos se suman a current_time como desplazamientos. El sufijo UTC evita supuestos de zona horaria. current_time admite los mismos formatos absolutos, pero nunca se trata como desplazamiento.
Use resultados deterministas en clientes y pruebas
Use esta capacidad para establecer los datos de cuota y permita que su aplicación decida si espera, encola, reduce la concurrencia o muestra un aviso. current_time es explícito por una razón: ningún reloj del sistema, solicitud de red, configuración regional ni valor aleatorio puede alterar la respuesta. Esto permite que el cálculo del navegador coincida con el de la API y que las pruebas sigan estables meses después. Las marcas anteriores a la hora indicada producen cero, algo útil con webhooks demorados o registros históricos. El navegador es gratuito y cada llamada automatizada cuesta $0.002 por elemento.
Preguntas técnicas
¿Cuánto cuesta una llamada a la API?
Cada elemento usa el precio base indicado como $0.002; la herramienta del navegador ejecuta localmente el mismo cálculo.
¿Por qué debo proporcionar current_time?
Una hora explícita mantiene deterministas los cálculos y permite reproducirlos en clientes y pruebas.
¿Qué ocurre si el reinicio ya pasó?
seconds_until_reset queda limitado a cero, mientras reset_at_unix conserva el instante absoluto analizado.