ForHosting KIT · Utilidades de desarrollo

Cree un calendario de rotación de contraseñas

Una política de rotación de contraseñas solo resulta útil cuando sus fechas permiten actuar.

● BetaGratis · en su navegador
Úselo desde WebAPIEmailTelegramApp pronto

Esta calculadora toma la fecha del último cambio, suma el intervalo de rotación exigido y retrocede desde el vencimiento para fijar un aviso previo. Devuelve fechas ISO exactas que usted puede copiar en una incidencia, un calendario, un inventario, un procedimiento o un flujo automatizado. Los años bisiestos y las distintas duraciones de los meses se tratan correctamente, sin aproximar noventa días como tres meses ni mantener fórmulas por cuenta.

Convierta una política de rotación en dos fechas útiles

Comience por la fecha real del último cambio de la contraseña, no por el día en que alguien la registró o revisó la cuenta. Introduzca el valor en formato YYYY-MM-DD y el intervalo de la política como un número entero positivo de días naturales. La calculadora suma exactamente esos días para obtener el próximo vencimiento. Después resta el plazo del aviso para indicar cuándo debe comenzar la preparación. Así, un intervalo de noventa días con catorce días de antelación genera tanto el plazo obligatorio como un activador operativo anterior. La diferencia es importante: el vencimiento por sí solo no reserva una ventana de mantenimiento, asigna una persona responsable ni permite probar el secreto sustituto. El resultado conserva los intervalos junto a ambas fechas para facilitar su revisión. Use cero días si desea avisar el mismo día del vencimiento; en los demás casos, deje tiempo suficiente para las aprobaciones y el despliegue de la cuenta.

Comprenda el cálculo por días naturales y la validación

El calendario usa días naturales, no laborables ni cálculos basados en meses. Un intervalo de treinta días siempre avanza treinta cambios de medianoche, aunque cruce febrero, un día bisiesto, el final de un mes de treinta y un días, un fin de semana o un festivo. El resultado respeta así las políticas expresadas como una cantidad fija de días y evita la ambigüedad de equiparar noventa días con tres meses. La fecha del último cambio debe ser una fecha gregoriana real con el formato estricto YYYY-MM-DD y ceros iniciales. Los valores imposibles, como el 30 de febrero, se rechazan. El intervalo de rotación debe ser un entero positivo; cero o los valores negativos no describen un periodo futuro. La antelación debe ser un entero no negativo. Puede superar el intervalo si el aviso resultante permanece dentro del calendario admitido, aunque tal configuración debe revisarse. No se consulta el reloj actual, por lo que una misma entrada siempre produce la misma salida.

Integre el resultado en un proceso de seguridad repetible

Considere las fechas calculadas como datos de planificación, no como prueba de que una credencial se haya cambiado. Guarde el vencimiento y el aviso con el identificador de cuenta, la persona responsable del sistema, el método de rotación y las pruebas exigidas en su registro de controles. En la fecha del aviso, abra o actualice una tarea, confirme que la persona responsable conserva el acceso, prepare el sustituto e identifique cada servicio consumidor. Al vencer, compruebe el cambio y registre una nueva fecha de último cambio antes de calcular el siguiente ciclo. Para automatizarlo, invoque la API después de cada rotación satisfactoria y escriba las fechas devueltas en su sistema de incidencias o calendario. Cada solicitud cuesta $0.002. La función no usa la red ni recibe o inspecciona la contraseña; solo procesa metadatos de planificación. Si la política se expresa en meses, días laborables o excepciones de riesgo, evalúela por separado en lugar de fingir que es un intervalo fijo de días.

Programe rotaciones de cuentas de servicio

Cree un vencimiento y una fecha de preparación tras cada cambio confirmado de la contraseña de una cuenta de servicio.

Mantenga un registro de control de acceso

Añada campos ISO coherentes de aviso y vencimiento al inventario de credenciales gestionadas sin almacenar contraseñas.

Active tareas de rotación

Calcule las fechas que un flujo automatizado debe usar para abrir una tarea y exigir su finalización.

¿Cuánto cuesta un cálculo?

Cada solicitud a la API cuesta $0.002; la herramienta web también puede calcular el calendario localmente.

¿Necesita la calculadora la propia contraseña?

No. Solo usa la fecha del último cambio, el intervalo de rotación y la antelación del aviso.

¿Cómo se calcula el próximo vencimiento?

El intervalo positivo se suma como una cantidad exacta de días naturales a la fecha del último cambio.

¿Admite años bisiestos y cambios de mes?

Sí. Valida fechas gregorianas y considera los días bisiestos y la duración real de cada mes.

¿Puede coincidir el aviso con el vencimiento?

Sí. Establezca reminder_days_before en cero para obtener la misma fecha de aviso y vencimiento.

¿Omite fines de semana o festivos?

No. El intervalo y la antelación se expresan en días naturales, por lo que ambos cuentan con normalidad.

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.

POSThttps://api.kit.forhosting.com/final3/password-change-reminder-schedule

¿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.

curl -X POST https://api.kit.forhosting.com/final3/password-change-reminder-schedule \
  -H "Authorization: Bearer $KIT_KEY" \
  -H "Content-Type: application/json" \
  -d '{"last_changed_date":"2026-01-15","rotation_interval_days":90}'
{
  "last_changed_date": "2026-01-15",
  "rotation_interval_days": 90
}
{
  "task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
  "type": "final3.password_change_reminder_schedule",
  "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.

Por solicitud$0.002

Precio publicado — sin tokens ni créditos inventados. Una tarea fallida no se cobra.

HTTPCódigoSignificado
401unauthorizedAPI key ausente o inválida.
402insufficient_balanceEl saldo no cubre el precio de la tarea.
404unknown_typeEl tipo de tarea no existe.
429rate_limitedDemasiadas peticiones. Use el webhook en vez de sondear.

Ver la documentación completa del KIT →