Moderation API

Platform overview

Send normalized events over Bearer API keys. Keep product tiers, routing, and enforcement in your integration layer.

Platform boundary

What the platform owns, and what it should never own

The clean integration line is simple: the platform owns moderation analysis, incidents, and credit accounting. Your adapter still owns product tiers, routing rules, tenant configuration, and the enforcement action taken inside the source product.

01Model your content the way it happened

Normalize the event once, with actor ids, scope ids, raw text, and attachments, before moderation starts.

02Pass your own policy and spend hints

Tenant plan logic, routing rules, and scan depth stay in your adapter and are expressed as request metadata.

03Use the verdict, but keep enforcement local

Platform decides moderation status; your product still decides whether to delete, hide, rate-limit, or escalate.

How it works

From event to verdict

Send an event, get a verdict, and enforce the outcome in your product. The platform handles analysis; your adapter handles tiers, routing, and enforcement.

01Event ingest

Your adapter submits normalized content through POST /v1/events.

02Moderation analysis

Policy and media pipelines run and produce category scores and confidence signals.

03Verdict + usage

Response returns decision status, evidence, and creditsConsumed.

04Incident + enforcement

Operators review incidents; your product decides delete, hide, queue, or allow.

Docs map

Pick a page by task

Start with quickstart, then schema, responses, and billing as you wire the integration.

Endpoint map

Core endpoints first

Start with event ingest, incident inspection, credits, and API keys. Add the rest once the core loop is observable.

POST/v1/events

Submit normalized content events for moderation in sync or async mode.

  • Requires: Bearer API key
  • Body: { mode, event, options? }
GET/v1/incidents

List incidents for a workspace with optional operator-focused filters.

  • Requires: incidents:read scope (or admin token)
  • Query: scopeId, severity/status CSV, q, customInfo*, includeRecommendedActions
GET/v1/incidents/:id

Fetch one incident by id for a specific workspace scope.

  • Requires: scopeId query required
  • Query: scopeId, includeRecommendedActions?
PATCH/v1/incidents/:id

Update incident triage status.

  • Requires: scopeId query required
  • Body: { status } (for example resolved or dismissed)