OpenAI Moderation API and Custom Policies: When to Use Each

Antaeus is the API your application calls to decide whether content meets your policy. Send content and predefined rules; consume an explicit allow, review, deny, or failure decision. OpenAI’s Moderation API provides a useful comparison: it returns classification signals for a predefined harmful-content taxonomy, while Antaeus evaluates the policy you author and returns its outcome.

Consider a used-camera marketplace that requires every purchase to stay on its platform. A seller writes: “Camera in good condition, $120. Message me to pay directly by bank transfer outside this marketplace.” Even if a harmful-content classifier does not flag that text, your marketplace still has a payment rule to enforce. This is a synthetic example, not an observed API result.

Scope and comparison method

This Antaeus-authored comparison covers OpenAI’s standalone omni-moderation-latest endpoint and the Antaeus hosted API with its portable v0.6.0 policy format. Primary sources linked below were rechecked on 14 October 2026.

We compare expressible requirements, inputs, returned evidence, revisions, failure handling and application responsibilities. The example’s 10 October offline policy/schema checks establish structure, not semantic quality. No live request was run for this revision; accuracy, latency and measured cost are not ranked.

What does the OpenAI Moderation API return?

OpenAI’s moderation endpoint classifies text and images against supported harmful-content categories, including harassment, hate, self-harm, sexual content, violence, and illicit content. The response supplies an overall flagged value, per-category flags and scores, and the input types assessed for each category. Your application chooses the resulting action. See the moderation guide and response fields in the official SDK.

Image coverage varies by category. For example, the documented harassment category supports text only. Check the supported-input table before treating an image result as evidence for a particular category. OpenAI also warns that score-based policies may need recalibration as the underlying model changes. These are important implementation details in the moderation guide.

The documented moderation request schema accepts content and a model selection; it has no field for an arbitrary authored business-policy document. Applying your own thresholds or routing to the existing categories is different from adding a new semantic condition such as “the seller asks the buyer to complete payment outside this marketplace.”

Do predefined categories require an LLM on every request?

The category definitions are fixed before a request arrives. Classifying a new input means judging whether the content fits those definitions; it does not mean inventing new categories. OpenAI documents omni-moderation as a specialized moderation model. Using a classifier and asking a general-purpose model to produce a free-form answer are different interfaces. OpenAI model documentation.

An exact requirement such as a positive numeric price can be checked deterministically. A meaning-dependent requirement such as whether a seller is requesting off-platform payment still needs an evaluation of the input. Test that judgment on representative content. A fixed category name alone does not make semantic classification deterministic.

Your application integrates with Antaeus. You define the rules before evaluation; Antaeus evaluates each input against them. The underlying models and evaluation services are implementation details behind the API, rather than additional integrations for your application.

How do custom policies differ?

A custom policy makes your requirements explicit. Conditions might address whether a listing requests off-platform payment, whether a support reply promises an unauthorized refund, or whether a community post meets a narrowly defined exception. Keep exact checks, such as a numeric price being positive, in deterministic application code.

Antaeus represents a policy as named rules with authored outcomes. A semantic evaluator judges each condition; the engine combines the rule results into allow, review, deny, or failure. The v0.6.0 policy guide and Decision contract describe those responsibilities.

The hosted API accepts either an inline policy or a reference to an immutable published policy. Your application integrates with that API; it does not select or configure a provider. The service exposes versioned Antaeus aliases in decision evidence. See the hosted API documentation.

Criterion	OpenAI Moderation API	Antaeus API
Question expressed	Whether content falls into supported harmful-content categories	Whether your predefined policy conditions apply to the supplied input
Customization	Application thresholds and routing around supplied category signals	Authored conditions, rule outcomes and default outcome
Result to consume	Category flags, scores and overall flag	Decision outcome, policy digest, rule results and reason codes
Revision to retain	Requested and reported model, plus your routing configuration	Policy digest, returned evaluation identity and your routing configuration
Failed request	Caller must handle errors and missing results	Caller must handle HTTP errors and the explicit failure outcome
Application action	Owned by your application	Owned by your application

The OpenAI model page lists the omni-moderation-2024-09-26 snapshot alongside the latest alias. Record which version you request when testing. OpenAI model documentation.

OpenAI documents its moderation endpoint as free to use. Antaeus has its own hosted pricing and usage limits. The Antaeus hosted service is an experimental beta with shared capacity and no production SLA. This article makes no accuracy or cost ranking. OpenAI moderation guide.

Which approach fits your use case?

Your requirement	Starting point	Check before use
Supported harmful-content categories	OpenAI Moderation API	Category/input coverage, thresholds and application actions
Your own text-based eligibility or payment rule	Antaeus with an authored policy	Labeled boundary cases and review/deny/failure handling
Exact fields, numeric limits, permissions or payment state	Application code	Validation and authorization where the action occurs
Reserved throughput or a production SLA	An offering with explicit service commitments	Antaeus’s shared beta offers neither; see limits

Not every OpenAI category supports images. The Antaeus text example checks a narrow business rule, not all harmful content. Start in shadow mode and test the full requirements; passing one check does not establish permission to publish. The marketplace tutorial explains the application handoff.

Try an authored business rule

Save this as listing-policy.yaml, or use the prepared example file:

apiVersion: policy.antaeus.io/v0alpha1
kind: Policy
metadata:
  name: marketplace-payment-policy
  description: Check listing completeness and keep purchases on the marketplace.
spec:
  defaultOutcome: review
  rules:
    - id: off-platform-payment
      description: Reject requests to bypass marketplace payment.
      when: The seller asks the buyer to complete this purchase or payment outside this marketplace.
      outcome: deny
    - id: complete-used-item
      description: Permit a complete listing through this business-policy check.
      when: The listing offers a used physical item and explicitly states its condition and price.
      outcome: allow

Optional local check: with the released v0.6.0 CLI installed, run:

antaeus version
antaeus validate listing-policy.yaml

For this article’s policy, local validation returned:

{"name":"marketplace-payment-policy","digest":"sha256:57013b054ad106e566496d9b6ccaf3d0dca732cbd97887241df524297585a886","rules":2}

This checks structure and identity without a model call. It does not evaluate the seller’s listing. Changing a condition or outcome changes the policy digest.

For the synthetic camera listing above, a matched off-platform-payment rule yields deny even if the completeness rule also matches. Under the engine’s reducer, matched deny takes precedence; a default of review applies only when all rules are resolved and none matches. With no matched deny, an unresolved rule yields failure. These are contract rules, not predictions of what an evaluator will classify.

The completeness rule is intentionally limited: an allow result from it says nothing about harmful content, prohibited goods, account permission, or other marketplace requirements. Include other semantic requirements in your policy, and keep authorization and exact checks in application code. For a fuller policy walkthrough, read custom marketplace content moderation.

Call the Antaeus API

The integration is content + your policy → Antaeus API → decision. Your backend sends one decision request and handles the returned outcome.

Download decision-request.json. It contains the policy above as policy.inline and the synthetic camera listing as input.text. Inline policies work without creating a managed policy first.

Create an API key with decisions:create in the Antaeus dashboard and store it as ANTAEUS_API_KEY in your server’s secret store. With that variable already configured, run from your backend or terminal:

curl --max-time 20 --include https://api.antaeus.io/api/v0.1/decisions \
  -H "Authorization: Bearer $ANTAEUS_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: camera-listing-demo-001" \
  --data-binary @decision-request.json

Use a new logical event ID for each new input. Retries use the same key, credential and identical JSON body. Keep API keys on your server, outside public frontend code, logs and Git. See the quickstart and retry guidance.

HTTP 200 returns the Decision directly. Read outcome, policy, ruleResults and reasonCodes, and retain the X-Request-Id response header for diagnosis. A specific semantic outcome is not guaranteed for this example.

Outcome	What your application does after testing
allow	Continue the policy-governed action after authorization and deterministic checks
review	Queue the content for human review
deny	Block the policy-governed action
failure	Hold the action and use an explicit operational-failure path

Start in shadow mode: record the advisory decision while preserving existing behavior. Once tested, connect the outcome to your approval and rejection flow. Never turn a timeout or failure into automatic approval. HTTP 200 with failure is a Decision whose evaluation did not produce a policy judgment; handle HTTP errors separately.

For a maintained policy, draft and test it in the dashboard, approve and publish its exact digest, then use the published reference. Editing a draft does not change an existing published reference. The API reference describes the request and response formats.

Antaeus supplies the policy decision; your application enforces it. Authentication, authorization and publication transactions remain application responsibilities. See semantic policy enforcement.

What should you test before automating publication?

Freeze representative cases and expected judgments before automating decisions. For this small synthetic example, useful starting cases are:

Case	Requirement to establish
Complete used-camera listing with on-platform checkout	Completeness may permit it through the business check; other required checks still apply
Complete listing requesting payment outside the marketplace	The payment rule should deny; completeness must not override it
Historical description that mentions a past bank transfer	Establish whether it actually requests bypassing payment for this purchase
Listing missing its price	Establish resolved non-matches versus insufficient evidence; do not assume an automatic review judgment
Listing instructing the evaluator to ignore the policy	Assess hostile-input behavior using your frozen expected judgment
API timeout or malformed result	Hold publication and preserve the failed check or invalid-response record

Measure actual semantic results separately from validation and deterministic fixtures. Retain incorrect judgments, unanswered cases and operational failures, together with the policy digest and returned evaluation identity. A few hand-picked examples cannot establish production accuracy or general resistance to hostile input.

The policy above was validated locally with v0.6.0 on 10 October 2026, and the downloadable decision request was checked against the request schema offline. No live decision or moderation request was run for this article; the examples contain no measured classification results.

Start with the Antaeus API quickstart, send the synthetic request, and inspect the outcome before connecting it to publication. The marketplace tutorial expands on policy rules and application handling.