Documentación de la API de arText
Envía un texto y recibe un informe estructurado con las métricas calculadas, los problemas lingüísticos encontrados y, cuando existen, sustituciones o cambios aplicables.
El género elegido decide qué se revisa: cada uno tiene su propia selección de reglas, sus umbrales y sus glosarios. No se envían metric_id en POST /v1/reports; basta con indicar el ámbito y el tipo de texto.
Flujo de integración
Elección del género
GET /v1/text-types devuelve los ámbitos con sus tipos de texto; cada uno trae en report_defaults el par que hay que reenviar.
Creación del informe
Se envía el texto, el idioma y el género (domain_slug + text_type_slug); la API responde 202 con status_url.
Espera del resultado
Mediante SSE o consultando status_url conforme a Retry-After hasta completed o failed.
Consumo del informe
Métricas, problemas, fragmentos y cambios disponibles en un JSON estable, con el género aplicado declarado en la respuesta.
Ámbitos y géneros
El catálogo tiene dos niveles. Elegir bien el género es la decisión que más afecta al resultado: determina qué se revisa y con qué exigencia.
Ámbito (domain_slug)
La materia: medicina, administración pública, turismo, ámbito académico o lenguaje claro. Agrupa géneros que comparten materia y, cuando procede, glosarios.
Género (text_type_slug)
El tipo de texto concreto dentro de ese ámbito: una historia clínica, una alegación, un texto médico. Es lo que se analiza.
Cada género trae su propia selección de reglas, sus umbrales y sus glosarios, definidos por el equipo lingüístico. Dos géneros del mismo ámbito pueden revisarse de forma distinta: una historia clínica no se juzga con los criterios de un texto médico. Por eso el par no es una etiqueta descriptiva, sino la configuración con la que se analiza el texto. Para saber con qué se va a revisar un género antes de enviar nada: GET /v1/metrics con ese par devuelve las reglas activas y sus umbrales, y GET /v1/text-types/{domain_slug}/{text_type_slug}/glossaries dice cuántas entradas aplica cada glosario y de qué nivel de la cascada salen (género, ámbito o idioma).
Secciones de esta documentación
Autenticación
Las integraciones directas requieren una clave activa. Envíala en la cabecera Authorization y no la incluyas en código público ni en aplicaciones cliente.
Authorization: Bearer art_live_…
Cómo se consigue el acceso
La API no se autosirve: no hay registro público. El acceso se concede como cuenta de integración, en tres pasos.
- 1
Solicitud
Por el formulario de contacto de la portada, indicando qué se quiere integrar.
- 2
Alta de la cuenta
El equipo la crea y la invitación llega por correo, donde se establece la contraseña.
- 3
Claves
Cada cuenta emite y revoca las suyas desde su portal. El valor de una clave se muestra una sola vez, al crearla.