Resources
Learn how teams can integrate WriteGo detection into document review, risk routing, audit records, and writing-integrity workflows.
Open core guideUse GET /v1/capabilities to list the available platform capabilities and GET /v1/capabilities/content.detect/schema to inspect the current detector input contract. Treat the returned schema as the source of truth instead of hard-coding assumptions from a marketing page.
Platform requests use a WriteGo API key in the X-API-Key header. A detector client needs platform:runs:write to start a run and platform:runs:read to read its status; create the narrowest key your workflow needs and keep it outside browser page content, source control, and client logs.
Submit text to POST /v1/capabilities/content.detect/runs. Send an Idempotency-Key when a client may retry so the same logical submission is not unintentionally started twice. Store the returned run identifier with your own document reference rather than using submitted text as an identifier.
Read GET /v1/runs/{run_id} until the run reaches a terminal status. Keep the run ID, status, timestamps, capability version, relevant output, and your reviewer decision as separate fields so an audit record distinguishes model evidence from the human outcome.
Clients should handle non-success HTTP responses, structured error messages, timeouts, and terminal failed or canceled states. Use POST /v1/runs/{run_id}/cancel when work should stop, and apply bounded backoff instead of aggressive polling or automatic infinite retries.
API-based workflows should not end with a score. High-risk, low-confidence, short, translated, edited, or policy-sensitive documents should move into a human review queue with the source context, passage evidence, notes, retention rules, and an appeal or correction path.
A strong workflow includes document IDs, risk bands, confidence, reviewer routing, audit records, retention rules, and policy status for each reviewed submission.
No. API results should prioritize and route review. High-risk, low-confidence, or sensitive documents should move to a human reviewer before final action.
Start a detector run with POST /v1/capabilities/content.detect/runs and read it with GET /v1/runs/{run_id}. Check the public capability schema first because supported fields can evolve with the versioned platform contract.
Use a stable Idempotency-Key for retries of the same logical submission, apply bounded backoff, and store the returned run ID. Do not create a new key for every network retry because that can create duplicate runs.