Simple JSON input
Send the draft and one supported model name. The response returns plain text plus the model and processed word count.
REST API / text rewriting
Send a draft, choose a humanizer model, and receive a new version inside your own workflow. The response stays easy to edit, compare, and approve before it goes anywhere public.
Use the key from a private server environment.
curl --request POST \
--url https://api.detecting-ai.com/api/humanize/ \
--header "Content-Type: application/json" \
--header "Idempotency-Key: humanizer-review-001" \
--header "X-API-Key: YOUR_API_KEY" \
--data '{
"text": "Paste the text you want to rewrite.",
"model": "cognia"
}'POST requests to /api/humanize/
X-API-Key authentication
Client Idempotency-Key for recoverable retries
Four supported models
Word usage in every response
A rewriting step you control
A useful humanizer integration does not hide what changed. Store the original, request a rewrite, and give an editor a clear place to compare the two versions before approving the result.
Send the draft and one supported model name. The response returns plain text plus the model and processed word count.
Select cognia, lexi, cognia_v2, or huma_v2 based on the behavior your team has tested for its own content.
Put the returned text back into an editor, revision queue, or content system instead of treating it as a finished artifact.
Request contract
Both fields are required by the REST endpoint. Keep model selection in configuration so it can be tested and changed without rewriting the integration.
| Field | Type | Required | What it does |
|---|---|---|---|
| text | string | Yes | The supplied text you want the service to rewrite. |
| model | string | Yes | One of cognia, lexi, cognia_v2, or huma_v2. |
Use humanized_text as the editable result. Record model_used and words_processed beside it so support, billing, and content teams can understand how the request ran.
{
"humanized_text": "The rewritten text is returned here.",
"words_processed": 8,
"model_used": "cognia"
}Integration flow
The strongest workflow keeps the original visible and asks a person to approve the new version.
Store the key on your server or in a secret manager. Do not place it in public browser code or a shared document.
Choose one supported model, persist a unique Idempotency-Key before sending, and reuse that key only for an exact retry.
Check the rewritten text for accuracy, meaning, tone, and required terminology before saving or publishing it.
Good fits
Humanization is most useful when a draft already moves through review. The API adds a rewrite option without replacing the people responsible for the final words.
Names, quotations, figures, legal language, and technical terms deserve a careful check. Keep those details visible to the reviewer.
Offer a rewrite action inside a CMS and return the result to the same draft for comparison and approval.
Revise approved source material into clearer help text, then send it through the normal fact and policy review.
Add a rewrite candidate beside the original so an editor can keep, combine, or reject individual changes.
Call the service from a trusted backend and expose only the returned text your signed-in user needs.
API FAQ
Start with a server-side request, log the response shape, then add the result to your existing review flow.
Send a POST request to https://api.detecting-ai.com/api/humanize/. Use JSON, pass your key in X-API-Key, and persist a stable Idempotency-Key for every logical operation so retries are recoverable.
The supported model values are cognia, lexi, cognia_v2, and huma_v2. The REST API expects the model field on every request.
A successful response contains humanized_text, words_processed, and model_used. The rewritten text remains editable in your product.
No. Review the result for meaning, facts, tone, names, links, and any language that must stay exact. A rewrite can improve flow while still needing an editor.
Usage is based on the input word count and comes from the humanizer balance attached to the API subscription. Successful responses report words_processed.
Build the first request
Start with one model, compare the result against the source, and decide which checks your editors need before the feature ships.