How to Use the WatermarkRemoverPro API to Check AI Marks

Step 1: Create an account and generate an API key

Start on the Pricing page and sign up for a Pro account, because the API and MCP server sit behind that tier, metered separately at 2p per 1,000 words on top of the subscription.

Once you're in, open the API keys panel in your dashboard and generate a new key. It will look something like mw_live_9f2..., so copy it once and store it somewhere safe, because WatermarkRemoverPro won't show you the full string again.

Treat the key like a password. If it ever ends up in a public repository or a client-side bundle, revoke it from the dashboard immediately and generate a fresh one.

Step 2: Send your first request to POST /api/v1/check

Every check goes through one endpoint: POST /api/v1/check. Set the Authorization header to Bearer mw_live_your_key_here, and send a JSON body with the document text and a language code: en, es, fr, de or pt.

A minimal request might carry just two fields: text and language. The API doesn't care whether the call comes from a script, a CI job, or an agent, since it treats every caller the same way.

Unlike the free Check page, there's no 1,500-word ceiling here. The API is metered instead, so longer documents simply cost more, billed per 1,000 words.

Step 3: Read the response, covering signal strength, confidence band and passage breakdown

A successful call returns a JSON object with a headline signal strength figure and a confidence band around it, exactly as you'd see on the Check page or in the evidence report PDF.

Below that sits a per-passage breakdown, an array showing how the signal varied across the document, which matters because a mark can be strong in one section and absent in another if text was mixed or edited unevenly.

The response also carries a limits array: short strings stating the method's own caveats, including that a detected mark is not proof of authorship and an absent mark is not proof of human authorship. Build your integration to surface these, not just the headline number.

For a concrete sense of the shape, a typical response looks roughly like a top-level object carrying a signal strength figure between 0 and 100, a confidence band object giving a lower and upper bound around that figure, a passages array where each entry carries its own local signal strength alongside the character range it covers, and the limits array of short caveat strings described above. Parsing this once, into a typed struct or interface in your own codebase, then reusing it everywhere you call the endpoint saves you from re-deriving the shape from raw JSON on every integration. Treat the top-level signal strength as a headline for humans, and treat the passages array as the thing your automation actually reasons over, because that is where uneven or mixed-origin text shows up first.

Step 4: Handle the 401, 402, 400 and 405 responses

A 401 means your Authorization header is missing, malformed, or the key has been revoked. Check the header format first, since it's the most common integration mistake.

A 402 means you've hit a usage or billing limit. The response names the exact limit you hit, so your error handling can tell a user precisely what to do next, rather than showing a generic failure.

A 400 means the request body itself was malformed: a missing text field, an unsupported language code, or invalid JSON. A 405 means you called the endpoint with the wrong HTTP method; /api/v1/check only accepts POST.

Step 5: Understand the 2p-per-1,000-words metering and the 503 refusal

Billing is straightforward: 2p per 1,000 words checked, tracked against a usage ledger tied to your account. There's no separate free tier on the API itself. Pro unlocks access, and metering covers usage from there.

If that usage ledger is ever unavailable, the API returns 503 rather than quietly serving the check for free. That's a deliberate choice: WatermarkRemoverPro refuses to give away a result it can't bill correctly, instead of guessing.

Design your integration to retry a 503 with backoff, the same way you'd treat any other transient outage, because it usually clears within minutes.

In practice that means treating a 503 the way you would any other transient failure: wait a second, retry, and if it fails again, double the wait before the next attempt, capping out after four or five tries rather than retrying forever. A short jitter added to each wait, a few hundred milliseconds picked at random, stops every client in a busy pipeline from hammering the endpoint at exactly the same instant once the ledger recovers. Most outages clear well inside that window, so a caller with backoff built in rarely needs to surface the failure to a human at all, while a caller without it risks turning a brief, minutes-long blip into a support ticket.

Step 6: Call it from an agent, using the MCP server's check_document and describe_method tools

For agent-based callers, raw HTTP is not always the natural fit. The MCP server exposes the same functionality as two tools: check_document, which runs the watermark check on a passed-in document, and describe_method, which returns the method's description and stated limits as structured data.

That second tool matters more than it sounds. An agent that needs to disclose provenance before handing off a document, whether to an editor, a client, or a downstream system, can call describe_method first to fetch the exact limits language, rather than paraphrasing it and risking a claim the method does not support.

Wire check_document into any workflow where an agent produces or forwards text and needs a documented, falsifiable check attached before that handoff happens.