arText API documentation
Submit text and receive a structured report containing calculated metrics, detected language issues and, where available, applicable replacements or edits.
The chosen genre decides what is reviewed: each one has its own selection of rules, its own thresholds and its own glossaries. You do not send metric_id values to POST /v1/reports; the domain and text type are enough.
Integration flow
Choosing the genre
GET /v1/text-types returns the domains with their text types; each one carries in report_defaults the pair to send back.
Report creation
The text, the language and the genre (domain_slug + text_type_slug) are submitted; the API returns 202 with status_url.
Waiting for the result
Through SSE or by polling status_url honoring Retry-After until completed or failed.
Report consumption
Metrics, issues, source fragments and available edits in a stable JSON, with the applied genre declared in the response.
Domains and genres
The catalog has two levels. Choosing the right genre is the decision that most affects the result: it determines what is reviewed and how strictly.
Domain (domain_slug)
The subject area: medicine, public administration, tourism, academic writing or plain language. It groups genres that share a subject and, where applicable, glossaries.
Genre (text_type_slug)
The specific type of text within that domain: a clinical history, a formal objection, a medical text. This is what gets analyzed.
Every genre carries its own selection of rules, its own thresholds and its own glossaries, defined by the editorial team. Two genres in the same domain can be reviewed differently: a clinical history is not judged by the standards of a medical text. The pair is therefore not a descriptive label but the configuration the text is analyzed with. To find out how a genre will be reviewed before submitting anything: GET /v1/metrics with that pair returns the enabled rules and their thresholds, and GET /v1/text-types/{domain_slug}/{text_type_slug}/glossaries reports how many entries each glossary resolves and which cascade level they come from (genre, domain or language).
Sections of this documentation
Authentication
Direct integrations require an active key. Send it in the Authorization header and never include it in public code or client applications.
Authorization: Bearer art_live_…
How access is granted
The API is not self-service: there is no public sign-up. Access is granted as an integration account, in three steps.
- 1
Request
Through the contact form on the home page, stating what you want to integrate.
- 2
Account creation
The team creates it and the invitation arrives by email, where the password is set.
- 3
Keys
Every account issues and revokes its own from its portal. A key value is shown once, when it is created.