Changelog
Le entrega al endpoint un lote de mensajes de commit o un resumen de diff desde la última versión publicada, y devuelve notas de lanzamiento escritas para quien realmente las va a leer: agrupadas en funciones nuevas, correcciones y cambios incompatibles, no un historial crudo de commits. Está pensado para ese paso del lanzamiento que los equipos de ingeniería siempre planean hacer bien y casi nunca tienen tiempo de hacer.
Ejecútela online
Ejecute esto en nuestros servidores con su cuenta. Las herramientas gratuitas corren en su navegador; esta cobra de su saldo del KIT según el precio de arriba.
La distancia entre los commits y las notas de versión
Un historial de commits está escrito para quien hizo el commit, en el momento en que lo hizo: 'fix null check', 'wip', 'atender comentarios de revisión', que es exactamente el registro equivocado para alguien que está decidiendo si actualizar o no. Las notas de versión tienen que decir qué cambió para el usuario, no qué cambió en el código, y ese paso de traducción es donde la calidad de un changelog suele venirse abajo bajo presión de tiempo. Este endpoint hace justo esa traducción: toma los mensajes de commit en bruto y los agrupa en las categorías que un lector realmente busca, reescribiendo cada entrada en términos claros.
Cómo se estructura la solicitud
Se hace POST a /text/changelog con los mensajes de commit o el resumen de diff correspondientes al lanzamiento. La tarea corre de forma asíncrona: el task_id llega de inmediato, y el changelog terminado se entrega por webhook firmado o por un enlace firmado válido durante 24 horas, lo que encaja de forma natural en un pipeline de integración continua que lo dispara automáticamente al crear la etiqueta de versión, sin esperar a que una persona escriba las notas a mano antes de cada lanzamiento.
Por qué agrupar es prácticamente todo el trabajo
La convención 'Keep a Changelog', hacia la que ha convergido buena parte de la industria, existe porque una lista cronológica y plana de commits no comunica riesgo: el lector necesita ver los cambios incompatibles separados de las correcciones rutinarias antes que cualquier otra cosa, porque esa es la única categoría que decide si una actualización necesita planificación. Este endpoint sigue ese mismo instinto: los cambios incompatibles, las funciones nuevas y las correcciones se agrupan en secciones distintas en lugar de mezclarse en el orden de los commits, así que la línea más importante para un lector cuidadoso no queda enterrada en la línea cuarenta de un desplazamiento largo.
Dónde encaja en un pipeline de lanzamientos
Está pensado para equipos que lanzan versiones con frecuencia y no quieren que alguien curara las notas a mano cada vez, mantenedores de proyectos de código abierto que le deben a sus usuarios una guía clara de actualización, y plataformas que generan notas de versión en nombre de muchos proyectos a la vez. Al ser asíncrono con entrega por webhook, un job de integración continua puede llamarlo en el momento en que se etiqueta una rama de lanzamiento y tener las notas listas antes de que el lanzamiento siquiera se publique. El precio es $0.003 por solicitud más $0.0135 por versión publicada, cobrado solo cuando el changelog se completa; las generaciones fallidas se reintentan automáticamente hasta tres veces sin costo.
Qué puede hacer con ella
Pipeline de lanzamientos automatizado
Un flujo de integración continua llama al endpoint en el momento en que se publica una etiqueta de versión, y adjunta las notas generadas al lanzamiento antes de que salga.
Mantenedor de proyecto de código abierto
Un mantenedor con poco tiempo para documentación envía los commits desde la última etiqueta y recibe notas claras y agrupadas en vez de saltarse el changelog en esa versión.
Plataforma que genera notas para muchos repositorios
Una plataforma de herramientas para desarrolladores que ofrece changelogs alojados los genera para cada proyecto conectado sin que una persona toque ninguno.
Cambios incompatibles bien resaltados
Una librería con una política estricta de versionado semántico usa la salida agrupada para asegurarse de que los cambios incompatibles nunca queden mezclados entre correcciones rutinarias.
Preguntas frecuentes
¿Es gratis la API para generar changelogs?
No hay capa gratuita: las capas gratis se abusan y ralentizan a todos. El acceso funciona con un saldo prepago de ForHosting KIT: se recarga desde $10.00 (no caduca) y cada solicitud se cobra a su precio publicado, así que una llamada sin saldo devuelve HTTP 402. Sin suscripción, sin tokens ni créditos inventados, y una tarea fallida no se cobra.
¿Solo reformatea mis mensajes de commit?
No, los reescribe en lenguaje claro orientado al usuario y los agrupa por categoría, en lugar de simplemente reformatear el texto crudo del commit.
¿Separa los cambios incompatibles de las correcciones normales?
Sí, los cambios incompatibles, las funciones nuevas y las correcciones se agrupan en secciones distintas para que las entradas más importantes de cara a una decisión de actualización no se mezclen con commits rutinarios.
¿Puedo dispararlo automáticamente desde CI/CD?
Sí: envíe los mensajes de commit o el resumen de diff al momento de crear la etiqueta mediante POST a /text/changelog y gestione el resultado por webhook, sin ningún paso manual.
¿Cómo recibo el changelog terminado?
Por webhook firmado, recomendado para pipelines automatizados, o por un enlace firmado válido durante 24 horas si prefiere consultarlo cuando lo necesite.
¿Puedo generar changelogs para varios proyectos a la vez?
Sí: cada llamada a /text/changelog es una tarea asíncrona independiente, así que una plataforma puede procesar los lanzamientos de muchos proyectos en paralelo.
¿Qué formato de entrada espera?
Mensajes de commit en bruto o un resumen de diff del lanzamiento; no exige una sintaxis especial como conventional commits, aunque seguir una ayuda a que la agrupación sea mejor.
¿Se conservan mis datos de commits después?
No: se eliminan al terminar el periodo de retención y nunca se usan para entrenamiento; el único rol del endpoint es producir el changelog.
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, y pronto desde nuestra app, el email y Telegram.
Llámela desde su stack
curl -X POST https://api.kit.forhosting.com/text/changelog \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"input":"…"}'const res = await fetch("https://api.kit.forhosting.com/text/changelog", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"input": "…"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/text/changelog",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"input": "…"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/text/changelog", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"input":"…"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"input":"…"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/text/changelog", 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
{
"input": "…"
}Ejemplo de respuesta
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "text.changelog",
"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.
Límites
max_tokens | 20000 |
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. |
422 | task_failed | La tarea falló tras 3 reintentos. No se cobra. |