Consent & Adult Content

This guide documents the current backend rules for:

• third-party consent
• creator tagging
• adult-content flags
• buyer age checks
• creator verification dependencies

Core product flags

The product update/create flow currently supports:

• is_adult_content
• is_verif_age
• is_should_consent
• is_downloadable

These flags control different parts of the workflow and should not be treated as interchangeable.

is_should_consent on the product is a derived summary flag: it is true when at least one linked media item has media.is_should_consent = true. The live consent workflow (tags, admin review, purchase blocking) is scoped to individual media rows.

Media-level consent workflow

Each upload (media row) can require third-party consent independently:

Field / relation	Scope	Purpose
media.is_should_consent	Per upload	Whether this specific file needs a 2257 / creator-tag workflow
consent_creator_tags.media_id	Per upload	Tags and admin consent slots belong to one media item
consent_creator_tags.product_id	Product	Kept for seller APIs and reporting
products.is_should_consent	Product (derived)	true if any linked media requires consent

Admin → Uploads shows consent status per row. Purchase / explore evaluate the whole product: if any linked media has open or blocking consent, the product stays non-purchasable.

Creator tagging via POST /api/consents/store-or-send applies to the product’s primary media (first linked upload) when media exists.

Adult-content flag

is_adult_content marks a product as adult content.

This affects:

• product compliance behavior
• buyer gating rules
• creator-side defaults

Buyer age check

is_verif_age controls whether the buyer must pass age verification before access/purchase where applicable.

Important:

• age-check logic is separate from creator identity verification
• a product can be adult content without every creator-side verification workflow being the same

Creator identity verification

Fangate uses creator verification flows such as Veriff for seller identity/KYC concerns. This is separate from the buyer-facing age-check journey.

The consent-tag response flow can also require Veriff before a tagged creator may accept or decline a tag request.

Third-party consent requirement

is_should_consent signals that third-party consent handling applies. On products, treat it as a summary flag. On media, it is the source of truth for whether that upload needs tags / admin consent review.

The current backend supports three mutually exclusive consent-submission modes in:

• POST /api/consents/store-or-send

Modes:

1. tag one or more Fangate creators
2. send consent by email
3. upload at least three consent documents

Consent document rules

For document upload mode, the current backend requires:

• at least three files
• each file max 10 MB
• accepted mime types: pdf, jpg, jpeg, png

Creator tagging behavior

Relevant endpoints:

• GET /api/creators/search
• POST /api/consents/store-or-send
• GET /api/products/{product}/consent-creator-tags
• GET /api/consent-tags
• PATCH /api/consent-tags/{consentCreatorTag}

Current backend rules:

• seller cannot tag themselves
• duplicate pending/accepted tag requests on the same media item are blocked (unique per media_id + tagged_user_id)
• if the same seller and tagged user already have an accepted relationship on another product, a new tag can auto-create as accepted
• if email-only consent is submitted for an email that already belongs to a registered Fangate user, the backend converts that into the creator-tag flow instead of treating it as a purely external email-only request
• when the product already has media, tagging targets the primary media on that product (first linked upload)

Tagged creator verification gate

If the tagged creator is not Veriff-verified, the backend does not immediately accept or decline the request.

Instead, it responds with verification-required data, and the client must:

1. start/complete verification
2. retry the same decision request

Product-level consent summary

For 2257 / consent creator tags, list/detail APIs and admin product views expose a product-level summary computed from all tags on the product and from any media with is_should_consent = true:

Summary label	Typical meaning
No consent	No linked media requires consent, and no blocking tag workflow applies
Pending	At least one tag is still pending, or consent is required on a media row but no one has been tagged yet
Accepted	Required tags are fulfilled (accepted/provided); no pending/declined/rescinded tags
Declined	At least one tag is declined or rescinded

In Admin → Uploads, each row shows the per-media workflow. A product with two files can show one row as Consent provided and another as Consent requested.

That summary combines with moderation status (per media) to determine whether the product is purchasable.

Purchasability matrix (moderation × consent)

For products using 2257 / third-party consent creator tags, whether a buyer can purchase depends on both:

1. Moderation status (media / upload review), and
2. Consent status — per-media tags and media.is_should_consent, aggregated to a product summary for purchase checks.

Rule: A product is purchasable only when moderation is Approval or Manual approval, and consent is Accepted or No consent. Every other combination is non-purchasable.

Moderation ↓ / Consent →	Pending	Accepted	Declined	No consent
Unchecked	Non-purchasable	Non-purchasable	Non-purchasable	Non-purchasable
AI removal (with reason)	Non-purchasable	Non-purchasable	Non-purchasable	Non-purchasable
Approval	Non-purchasable	Purchasable	Non-purchasable	Purchasable
Manual approval	Non-purchasable	Purchasable	Non-purchasable	Purchasable
Manual removal	Non-purchasable	Non-purchasable	Non-purchasable	Non-purchasable

Notes:

• Consent: Pending — at least one tagged co-creator has not accepted or declined; product stays non-purchasable regardless of moderation.
• Consent: Declined — a tagged party declined (or consent was rescinded); non-purchasable regardless of moderation.
• No consent — no 2257 consent-tag workflow applies, or the product-level summary is “no consent” in admin; still requires Approval or Manual approval on the moderation side to be purchasable.
• Unchecked, AI removal, and Manual removal never yield a purchasable product in this matrix.

See also Content moderation — Uploads list for where these statuses appear in the admin Uploads view.

Per upload / product — status via API

What you need	Available on creator API today?	How
Moderation status (per media item)	Yes	GET /api/products (library) or product detail responses → each media[] item includes veriff_status (e.g. Unchecked, Approved, AI Removal, Manual Approval, Manual Removal) and optional removal_description.
Consent status (per media / product summary)	Partially	GET /api/products/{product}/consent-creator-tags returns each tag’s status and media_id. Group by media_id for per-upload UI. Product summary: any pending → Pending; any declined / rescinded → Declined; all required tags fulfilled → Accepted; no media requires consent → No consent. Product is_should_consent is a derived summary flag.
Overall purchasable (matrix outcome)	Yes	Each product in GET /api/products, collection list, and GET /api/products/{id} includes is_accessible (true / false), computed with the same rules as the matrix and checkout.

If the product cannot be loaded (deleted, forbidden, blocked owner), the API may return 404 — there is no body in that case. is_accessible is for rows returned in normal list/detail responses.

Example tag-request flow

1. seller searches creators with GET /api/creators/search?q=alice
2. seller submits POST /api/consents/store-or-send
3. tagged creator checks GET /api/consent-tags
4. tagged creator calls PATCH /api/consent-tags/{id} with decision=accept
5. if verification is required, the client completes Veriff and retries

Related

• Consents API
• Verification
• Products
• Content moderation