If you are building a CMS publish hook, an agency batch processor, or a content platform that moderates AI-generated submissions, the AI rewriter cannot live behind a paste-and-copy UI. It has to be an endpoint your code calls. TextSight ships a REST AI rewriter at api.textsight.ai with JSON in and JSON out, an SSE streaming variant for long jobs, three rewrite modes (Light, Balanced, Maximum) selectable per request, and webhook callbacks on the Business tier. The same endpoint powers the web app, the Chrome extension, and the WordPress plugin, so what you build against is the same backend every TextSight surface uses.
A paste-and-copy UI is fine for individual writers. It stops being fine the moment you are shipping software that processes content on behalf of users.
If your CMS asks the user to leave for a separate AI rewriter site and paste output back, you have lost the workflow. The Rewrite button has to live inside your editor, calling your backend, which calls the AI rewriter endpoint. The user never sees the dependency. TextSight's REST API is what makes that integration shape possible without rebuilding the model yourself.
Programmatic SEO platforms and content factories generate batches of drafts and need every piece rewritten and detector-checked before publish. That is a script, not a sequence of browser tabs. The API is the only way to wire detect, rewrite, re-detect, publish into a single automated flow. Run it nightly, run it on demand, run it from your CI pipeline.
If you are reselling authenticity to your own users, you need one upstream subscription, one set of credentials, and a pricing model that does not punish growth. Per-word credit packs do exactly that: every active customer eats your margin. A flat monthly subscription with a generous word quota on Business scales more predictably as your user base grows.
A small, stable JSON envelope. Two required fields. The rest are optional return-shape controls. The response is symmetric: the rewrite plus the metadata you asked for.
POST to https://api.textsight.ai/humanizer/v1/rewrite with a JSON body. Authentication is a single Authorization Bearer header carrying your API key. Content-Type is application/json. No OAuth choreography, no signed-request handshake, no per-endpoint scopes to manage. One key, one header, one endpoint.
text (required) is the source string to rewrite, up to roughly 20,000 characters per request. mode (required) is one of light, balanced, or maximum. The optional return block requests extras: score: true for the Authenticity Score, beforeAfterDetector: true for the detector score before and after the rewrite, or both.
The response is JSON with the rewritten text, the mode used, an Authenticity Score on a 0 to 100 scale when requested, and the before-and-after detector probabilities when requested. A meta block carries request latency, token counts, and the response identifier you can quote in support tickets. The shape stays the same across all three modes, so your parser handles them uniformly.
Light keeps the original sentence structure close and is right for content where exact meaning matters (technical writing, citations, voice-sensitive work). Balanced is the default and runs moderate rewrites suitable for most blog and article work. Maximum is the most aggressive and changes rhythm and vocabulary heavily; pair it with a Light first pass on voice-sensitive drafts so you do not flatten the writer's distinctive phrasing.
Free, Starter, and Pro cover the web app and extension. Business adds REST API access, the 150K monthly word quota, webhook callbacks, and a 100 requests per minute burst ceiling.
Billed $89.88/year — Save $30
Billed $179.88/year — Save $60
Billed $359.88/year — Save $120
Yearly billing saves 25%. View full pricing →
A single header on every request. No OAuth dance, no per-endpoint scopes to manage. The key is the only credential and rotating it is a single click in the dashboard.
Sign in to the web app and open the API Keys page in the dashboard. Click Generate, copy the value once (it is displayed a single time and never recoverable afterwards), and store it as an environment variable in your application. Treat it as a secret the same way you treat a database password. The key is visible only at creation; if you lose it, you generate a replacement and update your env.
Pass the key as Authorization: Bearer YOUR_API_KEY on every request. The endpoint reads it once per request, checks it against the issuing account's tier, and counts the request's word cost against that account's monthly quota. The same key works for rewrite, scan, summarize, and paraphrase endpoints, so you do not manage four credentials for four endpoints.
Keys are scoped to the issuing account, not per-endpoint. If a key leaks, revoke it from the API Keys page and generate a replacement; the revoked key returns 401 immediately on its next call. Keys inherit the tier limits of the account that created them, so a Business key carries the 150K monthly quota and the 100 requests per minute burst ceiling automatically.
No SDK ships yet because a thin wrapper in any language takes about 30 lines. The three snippets below cover the standard synchronous flow against the rewrite endpoint.
curl -X POST https://api.textsight.ai/humanizer/v1/rewrite \
-H "Authorization: Bearer $TEXTSIGHT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"text": "The draft to rewrite.",
"mode": "balanced",
"return": { "score": true, "beforeAfterDetector": true }
}'
const res = await fetch("https://api.textsight.ai/humanizer/v1/rewrite", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.TEXTSIGHT_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
text: draft,
mode: "balanced",
return: { score: true },
}),
});
const data = await res.json();
console.log(data.rewritten, data.humanizationScore);
import os, requests
resp = requests.post(
"https://api.textsight.ai/humanizer/v1/rewrite",
headers={"Authorization": f"Bearer {os.environ['TEXTSIGHT_API_KEY']}"},
json={
"text": draft,
"mode": "balanced",
"return": {"score": True},
},
timeout=60,
)
data = resp.json()
print(data["rewritten"], data["humanizationScore"])
{
"rewritten": "The rewritten, human-feeling version of the draft.",
"mode": "balanced",
"humanizationScore": 87,
"before": { "aiProbability": 94 },
"after": { "aiProbability": 12 },
"meta": {
"latencyMs": 1842,
"tokensIn": 421,
"tokensOut": 437,
"requestId": "req_01HX..."
}
}
An OpenAPI specification for the public endpoints is on the roadmap. Until it lands, the contract on this page and the /api-docs page is the source of truth. The endpoint shape has been stable since the extension and WordPress plugin shipped against it, so building today against the documented contract is safe.
Long rewrites are where a synchronous request hurts the most. A 5,000-word rewrite can take 20 to 40 seconds. Streaming lets you render output progressively or pipe partial output into a downstream stage.
Send the same POST payload to the same endpoint but set the Accept header to text/event-stream. The endpoint emits SSE frames carrying incremental chunks of the rewrite. The final frame carries the closing metadata (Authenticity Score, before/after detector scores) so you can finalize without an extra request to a status endpoint.
Streaming is right when you are rendering output progressively in a UI, piping into a downstream stage that can begin on partial output, or surfacing progress during a long job so the user does not think the tab broke. It is wrong when you need atomic responses for caching, when downstream tooling cannot consume partial JSON, or when a webhook callback would be a cleaner pattern (Business tier).
On Business, webhook callbacks deliver completion events to a URL you register. Submit a batch, return 202, and let the webhook fire when each job finishes. Right for CMS publish hooks where you want to rewrite a draft, queue it for editorial review, and notify the editor app when the rewrite lands. Webhooks and SSE solve different shapes of the same long-job problem.
Three integration patterns recur across customer pipelines. Each one runs on the same endpoint with different orchestration logic.
A pre-publish hook in your CMS calls the AI rewriter endpoint with the draft, waits on the response (or subscribes to a webhook on Business), and replaces the draft body with the rewritten version before the editor sees the publish-ready preview. Editors land on human-feeling prose without copy-pasting into a separate tool, and your platform looks like a single integrated workflow.
Content agencies queue client articles overnight and rewrite the batch in bulk. The script reads articles from a queue, calls the AI rewriter endpoint per article, writes the rewrite back with the Authenticity Score attached, and reports a per-client summary to a dashboard the next morning. The 150K monthly word quota on Business covers most mid-sized agency volumes; the 100 requests per minute burst handles the overnight burst pattern.
Platforms that accept user-submitted content (forums, marketplaces, knowledge bases) increasingly auto-rewrite AI-generated drafts to keep platform quality consistent. Detect first to flag AI-heavy submissions, route flagged drafts through the AI rewriter at Balanced mode, then publish the rewrite with an audit trail. Webhook callbacks let the moderation pipeline stay fully asynchronous.
The main AI rewriter landing page covering all source models, not just developer API access.
Open AI rewriter →Six detector APIs ranked for developers in 2026. Same REST surface as the AI rewriter.
Open the ranking →UI queue plus API workflows for teams processing large batches of drafts.
Read the guide →Full tier breakdown for Free, Starter, Pro, and Business. Annual billing saves 25%.
See pricing →REST + SSE streaming, three modes per request, webhook callbacks on Business, same backend as the web app and extension. Generate an API key in two minutes.