There is no TextSight app in the Zapier directory yet. We are not going to pretend otherwise on a page you found by searching for one. What does exist is a live REST API and Zapier's own Webhooks action, and together they do the same job a native listing would: a trigger fires, TextSight scores or rewrites the text, and the result comes back as mappable fields your later steps can branch on. This page is the exact setup, the exact field names, and the limits that will bite you.
TextSight is not currently listed in the Zapier app directory. A native listing would give you a searchable "TextSight" step with pre-filled fields. It is on our list, but it does not exist today, and every page that claims one for a tool in this category is worth checking before you trust it.
What works instead: Webhooks by Zapier pointed at https://api.textsight.ai. The endpoints take plain JSON with a single auth header, so Zapier needs no special support to call them. You lose the pre-filled dropdowns; you keep every capability.
Two costs to know up front. Webhooks by Zapier is a Premium action, so it needs a paid Zapier plan. And TextSight API keys are issued from Pro upward — Free and Starter accounts cannot create one.
This is the detection flow. Swap one URL at the end and it becomes the rewrite flow.
Sign in at app.textsight.ai on Pro or above and create a key. It looks like sk_live_…. Treat it like a password: a Zap stores it in plain configuration, so use a key issued for automation rather than reusing one from another system.
In your Zap, add an action step, search for Webhooks by Zapier, and pick the Custom Request event. Custom Request is the one that lets you set headers, which the simpler POST event does not do cleanly.
Fill the fields exactly like this, mapping text to whatever your trigger produced — a Google Docs body, a form answer, a Slack message:
If your HTTP client makes bearer tokens awkward, x-api-key: sk_live_… is accepted instead. Nothing else changes.
Run the test. Zapier parses the JSON response and splits it into individually mappable fields — this is the step people skip, and skipping it is why later steps show no options to map. After a successful test you will see humanization_score, ai_probability, verdict and the rest in the field picker.
Add a Filter or Paths step. Filter on verdict exactly matching ai, or on ai_probability greater than 0.7. Without this, every item continues down the Zap and you have built a logger rather than a check.
From POST /v2/detect. These are the real response keys, so what you see here is what appears in Zapier's field picker.
| Field | Type | What it holds |
|---|---|---|
humanization_score | 0–100 | How human the text reads. Higher is more human. |
ai_probability | 0–1 | The inverse view, as a probability. Easiest field to filter on numerically. |
verdict | enum | human below 0.3, mixed from 0.3 to 0.7, ai at 0.7 and above. |
confidence | number | How settled the result is. Low confidence is a reason to route for human review rather than auto-act. |
reasoning | string | A short written explanation. Useful as the body of a Slack alert. |
sentences | array | Each entry has text, its own score, and a label of ai or human. |
model | string | Which engine produced the result. |
request_id | string | Log this. It is what support needs to trace a specific call. |
Need less? POST /v2/score returns only humanization_score, ai_probability, confidence and request_id. Same engine, smaller payload — a good default when you are only filtering on a number.
Point the action at https://api.textsight.ai/v2/rewrite and it humanizes instead of scoring.
| Body field | Accepts | Notes |
|---|---|---|
text | string | Required. Up to 50,000 characters. |
tone | conversational, professional, academic, blog, email | Defaults to professional if omitted or unrecognised. |
strength | 1–5 | 1–2 light, 3 balanced, 4–5 aggressive. |
preserve | array of strings | Locked verbatim through the rewrite. This is how you protect citations, client names, product SKUs and figures. |
{
"text": "{{trigger_field}}",
"tone": "blog",
"strength": 3,
"preserve": ["TextSight", "Q3 2026", "£4,200"]
}It returns rewritten plus a fresh humanization_score and ai_probability, and a score_reliable boolean. When score_reliable is false the rewrite is still valid but the scoring was degraded — branch on it and re-scan rather than trusting the number.
The preserve array is the field most people miss. A rewrite that quietly rephrases a quoted source or a legal figure is worse than no rewrite. Populate it.
Each is a trigger, a webhook, a filter, and a destination. None needs more than four steps.
Google Docs → TextSight → Slack
A new doc lands in a shared Drafts folder. Score it, filter on verdict equals ai, and post reasoning plus the score into the editorial channel. Reviewers see the flag before they spend time on the piece.
Forms → TextSight → Sheets
Guest posts, applications, support tickets. Score each entry with /v2/score and append humanization_score and request_id to a sheet. No filter — the value is the trend line, not the alert.
Airtable → TextSight → Airtable
A row moves to "Ready to publish". Send the body to /v2/rewrite with your brand terms in preserve, write rewritten back to the row, and store the new score alongside it for the audit trail.
Every one of these has caused a broken automation somewhere. Better here than in production.
50,000 characters per call. Longer input returns a text_too_long error — it is not silently truncated. A Zap handling long documents must split the text or stop and alert, otherwise you will record a score for a document that was never scored.
Rate limits are per account, not per key. 60 requests a minute on Pro, 120 on Business, 240 on Enterprise. Issuing extra keys does not raise the ceiling; it only lets you scope and revoke them separately. A bulk Zap looping over 500 rows will hit this — add a delay step.
Handle the error codes. You may get invalid_request for a missing or empty text, text_too_long past the cap, rate_limited at the ceiling, and detector_unavailable when the engine is degraded. A Zap that assumes success will write empty values into your sheet on every one of these.
Detection is English-language. The API says so in its own discovery response. Scores on non-English text are not reliable enough to automate against, and a Zap that routes rejections on one is making decisions it cannot support.
A score is evidence, not proof. No detector is 100% accurate. Automating a consequence — rejecting an application, failing a student, cancelling a contract — off a single score is the wrong use of this API. Automate the routing: flag it, surface it, and let a person decide. See where the detector is weakest.
Because there is nothing Zapier-specific in the request, every one of these runs the identical call — and unlike Zapier, none of them puts generic HTTP behind a premium tier:
Make. The HTTP → Make a request module. Header support on every plan, and its bundle handling suits looping over many rows better than Zapier's.
n8n. The HTTP Request node, and self-hostable — the right answer when the text you are scoring cannot leave your infrastructure through a third-party SaaS.
Pipedream. Generous free tier and real code steps, so you can parse sentences properly instead of flattening it.
Google Apps Script. UrlFetchApp.fetch() covers Docs, Sheets and Gmail. The fastest route to scoring a column of drafts, with no third-party platform in the path at all.
No. There is no native listing today. The Webhooks by Zapier route above is the supported path, and it does the same job. We would rather document what works than list an app that does not exist.
For Zapier, yes — Webhooks is a Premium action. If you are picking an automation tool mainly to run TextSight, Make, n8n and Pipedream all include generic HTTP on their free tiers.
Pro or above. Free and Starter cannot create API keys. Per-minute limits are 60, 120 and 240 on Pro, Business and Enterprise, counted per account.
humanization_score, ai_probability, verdict, confidence, reasoning, a sentences array, model and request_id — all individually mappable once you have run the test.
50,000 characters. Beyond that you get text_too_long rather than a truncated result, so split long documents rather than assuming they scored.
Yes — point the same action at /v2/rewrite. It takes text plus optional tone, strength and a preserve array that survives the rewrite verbatim, and returns the rewritten text with a fresh score.
All integrations — every surface TextSight ships, and honest status on the ones it does not.
API documentation — full request and response shapes, error codes and worked examples.
AI humanizer API — what /v2/rewrite does to a draft and how it is scored afterwards.
Pricing — which tier issues keys, monthly and annual.
Detection limitations — required reading before you automate anything off a score.
API terms — the terms governing programmatic use.
Create an account, upgrade to Pro, issue a key, and paste it into a Webhooks step. The hardest part is deciding what to do with the score.