Content Moderation
This page describes the live backend moderation behavior that happens after uploads are attached to products.
Moderation pipeline overview
The current backend uses a mixed moderation model:
- image moderation through SightEngine
- video uploads handled outside the SightEngine image flow
- internal/manual review states surfaced through admin workflows
Image moderation
Images are checked server-side by the moderation job pipeline.
The public API does not ask clients to call SightEngine directly. Fangate handles:
- building the media URL or payload for moderation
- dispatching the moderation job
- storing the resulting verification/moderation status
Video moderation
Videos are moderated automatically as well: SightEngine checks sampled frames of each video (larger files are downloaded once and sampled locally). One case goes to manual review instead: videos above 2.5 GB are not checked automatically and stay pending until an admin has reviewed content and consent by hand - this manual review takes at most 24 hours.
Everything up to 2.5 GB is checked automatically, usually within minutes. Instead of polling, subscribe to the product.sellable webhook event: it is sent once, as soon as a product can be bought (see Webhooks). Its counterpart product.blocked tells you when the content was rejected - by the automated check (automatically_rejected_manual_review - the Fangate team reviews every automated rejection by hand, so this is not final) or by the Fangate team (manually_rejected) - or when a required consent is not approved (missing_consent). The file's status (GET /api/media/{media}) and the product's is_accessible / purchase_block_code stay available for reading the current state.
People count and automatic consent requests
The content check also counts the people in a file (videos: frames spread over the whole length). When it sees more than one person, a consent requirement is set on the file automatically - also when the upload did not declare one. The product is then blocked with purchase_block_code: consent_pending until the other person is tagged and has consented, and product.blocked reports it as missing_consent.
The count can be wrong: an object, for example a toy, is sometimes taken for a second person. The Fangate team therefore reviews automatically set consent requests by hand - as it does with every automated rejection - and lifts the ones set by mistake; product.sellable follows. Nothing has to be done on your side; if a file really shows a second person, tag that person (Consent & Adult Content).
Statuses used by the backend
The moderation / verification enum exposed through media records includes labels such as:
UncheckedApprovedAI RemovalManual Approval
These statuses are reflected in admin tooling and can affect whether content becomes purchasable or visible.
Consent and moderation both matter
Purchasability depends on more than moderation alone.
A product may still be blocked from purchase if:
- moderation is not in an allowed state
- third-party consent is pending or declined
Manual approval notifications
When media transitions into manual-approval workflows, the backend can dispatch creator notifications. The exact admin action surface is internal, but the resulting creator-facing state is part of the live behavior and should be expected in product workflows.
Uploads list: moderation status & consent status
In Admin → Uploads (internal), each row includes:
- Moderation status — derived from media verification/moderation state (e.g. Unchecked, Approved, Manual Approval, removals).
- Consent status — per upload (media row) summary of 2257 consent creator tags: No consent, Review open, Consent requested, Consent provided, Declined, or Consent rescinded. Each media item has its own workflow; two files on the same product can differ.
This helps operators see both media and co-creator consent at a glance.
Purchasability: A product is only purchasable when moderation is Approval or Manual approval and consent is Accepted or No consent. Full matrix (including pending/declined and removal states): Consent & adult content — Purchasability matrix.
Creator-facing apps should use the per-upload API fields documented there (not admin-only panels).
What integrators should do
- rely on product/media status returned by Fangate APIs
- do not hardcode direct SightEngine assumptions in clients
- do not build against internal admin moderation panels
- handle delayed availability after upload
Common moderation-related symptoms
Examples:
- product exists, but media is not yet purchasable
- preview exists, but content is still under review
- consent is accepted, but moderation is still blocking purchase
- a video item is waiting on manual approval instead of automatic approval