White-hat AI detector API

Humaniser's detector API is for review workflows, not accusation automation. It returns a passage-level verdict, sentence-level rationale, and scan details that record what the service scored.

Short answer

Use POST /v1/detect when a product needs to decide whether text should pass, be reviewed, or be held for editorial checks. The API should sit server-side behind your product, with a human reviewer making the final decision when the output affects hiring, grading, moderation, or publication risk.

What the detector returns

  • Verdict: human, ai, or manual_review.
  • Per-sentence verdicts: local rationale for the spans that moved the score.
  • Abstention: uncertain spans are marked abstain rather than forced into a binary label.
  • Scan details: available model, policy, result, and timing metadata.

Minimal request

curl -s https://api.humaniser.eu/v1/detect \
  -H "content-type: application/json" \
  -H "X-API-Key: $HUMANISER_API_KEY" \
  -d '{
    "text": "Paste the text to review here.",
    "threshold": 0.5,
    "min_words": 50
  }'

Representative response shape

Field names may evolve with the OpenAPI spec. Integrators should treat the local /openapi.json or production contract as the source of truth. 

{
  "verdict": "human | ai | manual_review",
  "confidence_band": "low | medium | high_confidence_ai",
  "score": 0.0,
  "sentences": [
    {
      "text": "Sentence under review.",
      "verdict": "human | ai | abstain",
      "rationale": ["low burstiness", "generic transition density"]
    }
  ],
  "scan_details": {
    "text_sha256": "...",
    "model_sha": "...",
    "calibration_card": "...",
    "created_at": "2026-07-01T00:00:00Z"
  }
}

White-hat integration rules

  • Do not use detector output as the only basis for a punitive decision.
  • Show sentence-level rationale to reviewers, not just a percentage.
  • Keep API keys on the server; never expose them in browser JavaScript.
  • Log the minimum scan metadata and reviewer decision, not the submitted text unless your DPA and retention choice allow it.
  • Run calibration checks on your own content before enforcing thresholds.

Good fit

The detector API fits editorial quality gates, academic-integrity triage, ad copy review, marketplace content moderation, and internal compliance queues where a review team needs explainable signals before publication.

ChargeIntel and KlarAds integration

ChargeIntel can use /v1/detect as a server-side quality gate before publishing billing, disputes, and regulatory copy. The expected behavior is to pass low-risk content, queue uncertain content, and attach scan details to the internal review record.

KlarAds and KlarAdsKit should treat detector output as launch metadata, not as a separate ad-ops stack. Campaign copy can emit a standardized detection result with the verdict, abstention state, scan-details reference, locale, and reviewer outcome so campaign tooling can compare launches without storing raw text in every downstream system.

Not a good fit

It is not a proof of authorship, a disciplinary engine, or a way to claim that one named person used a specific model. AI text detection is a probabilistic signal with false positives and false negatives; the product is designed to preserve that uncertainty.

Next steps