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.

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:

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 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:

1. start/complete verification
2. 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

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