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_contentis_verif_ageis_should_consentis_downloadable
These flags control different parts of the workflow and should not be treated as interchangeable.
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 the product requires third-party consent handling.
The current backend supports three mutually exclusive consent-submission modes in:
POST /api/consents/store-or-send
Modes:
- tag one or more Fangate creators
- send consent by email
- 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/searchPOST /api/consents/store-or-sendGET /api/products/{product}/consent-creator-tagsGET /api/consent-tagsPATCH /api/consent-tags/{consentCreatorTag}
Current backend rules:
- seller cannot tag themselves
- duplicate pending/accepted tag requests on the same product are blocked
- 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
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:
- start/complete verification
- retry the same decision request
Product-level consent summary
Admin-facing product consent state can resolve to values such as:
- no consent
- pending
- accepted
- declined
That status can combine with moderation state to determine whether the item is purchasable.
Purchasability rule
A product becomes purchasable only when the content is in an allowed moderation state and the consent state is not blocking purchase.
Practically:
- approved or manual-approval moderation can still be blocked by pending/declined consent
- no-consent or accepted-consent states can allow purchase when moderation is also acceptable
Example tag-request flow
- seller searches creators with
GET /api/creators/search?q=alice - seller submits
POST /api/consents/store-or-send - tagged creator checks
GET /api/consent-tags - tagged creator calls
PATCH /api/consent-tags/{id}withdecision=accept - if verification is required, the client completes Veriff and retries