AI Detection API: How to Add Content Checks to Your App

A practical guide to wiring AI content detection into your product, where to call it, how to handle scores, and the mistakes that cause false accusations.

If you run a platform where users submit writing, a marketplace, an LMS, a publishing tool, a hiring product, you will eventually be asked to flag AI-generated content. This is a guide to doing that without building something that misfires on your honest users.

The API mechanics are the easy part. The design decisions around them are what determine whether the feature helps or generates support tickets.

Decide what you are actually building

Before any code, answer this: what happens when the score comes back high?

The answer determines everything else. Four common designs, in ascending order of risk:

| Design | What it does | Risk |

|---|---|---|

| Author-facing | Writer sees their own score before submitting | Very low |

| Reviewer triage | Score sorts a moderation queue | Low |

| Soft gate | High scores require extra review | Moderate |

| Hard gate | High scores are auto-rejected | High, don't |

The hard gate is the one that gets platforms into trouble. Detection returns a probability, and probabilities at scale produce false positives with certainty. Auto-rejecting on a score means auto-rejecting honest work, disproportionately from non-native English writers, whose more uniform sentence structure reads as machine-like to every detector on the market. We covered that mechanism in why AI detectors falsely flag non-native English writers.

Build the author-facing version first if you can. It converts an adversarial feature into a helpful one and generates almost no disputes.

Where to put the call

Not on every keystroke. Debounce, or trigger on explicit action. Detection is priced per word and scores are unstable on partial text.

Not synchronously in the submit path. A detector call in the critical path of a form submission means an API hiccup becomes a failed submission. Queue it and update the record when the result lands.

Do it server-side. An API key in client code is a public API key.

A sane shape:

user submits
  persist immediately, status: pending_review
  enqueue detection job
  worker calls detector, writes score + per-sentence data
  status: reviewed
  reviewer UI reads the stored breakdown

If the detector is unavailable, the submission still succeeds and the job retries. Availability of your product should never depend on availability of a third-party classifier.

Store the breakdown, not just the number

The single most valuable implementation detail. Persist the sentence-level or region-level output, not only the headline percentage.

Reason: when a user disputes a flag, and they will, a stored percentage gives you nothing to discuss. A stored breakdown lets a human see that the score came from one boilerplate introduction rather than from the substance of the work. Most disputes evaporate at that point.

It also lets you re-evaluate historical decisions when you change thresholds, instead of re-scanning everything.

GPTOne includes API access on all paid tiers and returns sentence-level results, which is why we recommend it for this pattern specifically. Coverage spans ChatGPT and GPT-4, Claude, Gemini, Grok, DeepSeek-V3 and R1, Llama, Mistral and Mixtral, and Qwen, worth checking against whatever you integrate, because detectors trained mainly on GPT output degrade quietly on other families.

Budgeting: credits are words

Pricing is per word, so your cost model is a word-count model, not a request-count model. One credit covers one word.

Estimate before you build:

monthly_credits = submissions_per_month × avg_words × checks_per_submission

That last term is the one people forget. If you check on draft save and on submit, you have doubled your spend. Decide deliberately.

For reference on the current plans: Starter is 180,000 credits/month at $7.99, Pro 500,000 at $12.99, Elite 1,000,000 at $29.99. There is no per-scan word cap on any tier, so long documents go through in a single pass rather than needing chunking logic on your side, one less thing to build, and it avoids the inconsistent-scores-across-chunks problem.

If you need volume beyond Elite, that is an Enterprise conversation rather than a plan upgrade.

Threshold design

Do not pick a single number and ship it. Instead:

1. Run in shadow mode first. Score submissions, store results, act on nothing. Two weeks of your real traffic tells you more than any published benchmark, because your users are not the benchmark's users.
2. Look at the distribution. Where do your known-good submissions actually sit? If your platform is full of technical writing or non-native English, your honest baseline is higher than you expect.
3. Set bands, not a line. Low pass. Middle reviewer queue. High reviewer queue with priority. Note that no band auto-rejects.
4. Re-check quarterly. Models change, detectors retrain, your user mix shifts.

Things that will bite you

Short text. Below a few hundred words, scores are noisy. Set a minimum length and return "insufficient text" rather than a misleading number.

Quoted material. A submission that legitimately quotes sources at length may score high on the quoted portion. If your product involves citation-heavy writing, strip or flag quotations before scoring.

Non-prose content. Code blocks, tables, structured data and reference lists are not what these classifiers model. Extract prose first.

Retries and idempotency. Detection jobs that retry without an idempotency key will double-charge you. Key on content hash.

Caching. Identical text produces identical results. Hash the input and cache, on platforms with template-heavy submissions this cuts spend substantially.

What to show users

If your feature is author-facing, show the breakdown, not the verdict. "These three sentences read as machine-generated" is actionable. "78% AI" produces confusion and defensiveness.

If your feature is reviewer-facing, put the score next to the evidence and make the reviewer's decision the recorded one. Never surface a raw score to an end user as an accusation.

And write down your policy where users can read it before they submit. Most disputes are not about detector accuracy, they are about a rule nobody published. A disclosure policy prevents more conflict than any threshold tuning.

Images, if relevant

If your platform accepts uploads, the same architecture applies with different signals. Pixel-level detection survives metadata stripping, which matters because every platform strips EXIF on upload, see how to read image metadata and the image detector. Per-region output is essential there, because the common real case is an authentic photo with one generated element rather than a fully synthetic image.

The bottom line

Queue the call, never block submission on it, store the sentence-level breakdown rather than the score, run in shadow mode before enforcing anything, and never auto-reject on a probability. Get those five right and the integration itself is a few hours' work. Start with the detector on the free tier to see the response shape before you write any code.