Solo Creator

The Solo Creator flow is the right integration when each piece of content has exactly one performer and that performer is the uploader. OnlyFans-style creator platforms, clip stores, fan sites, and personal video pages all fit this pattern.

What you get

• A verified-identity record for every creator who uploads explicit content on your platform
• A per-depiction audit trail tying each piece of content to that record (28 CFR 75.2)
• Easy2257 named as the Custodian of Records on every 2257 statement, so your platform never stores government IDs
• The same verification covers the creator everywhere they upload: verify once, compliant on every Easy2257 partner platform

When to use this vs. Productions

Use Solo Creator when content involves only the uploader. Use Productions when content involves additional performers and needs per-scene consent collection.

Integration shape

Three endpoints, one status poll, and two webhooks you act on. Full code in the Quickstart.

0. register a webhook endpoint in the partner portal, copy the whsec_ secret
   (callbackUrl in the API body does NOT subscribe you to anything)

1. POST /v1/solo-accounts             ->  status: pending_id_verification
                                            + onboardingUrl
                                      ->  or status: active (already verified)

   redirect creator (top-level nav, NOT iframe, needs camera)

2. solo_account.verified webhook      ->  grant upload access
   solo_account.suspended webhook     ->  revoke upload access

   GET /v1/solo-accounts/{id}         ->  poll for certainty / reconcile

3. POST /v1/solo-accounts/{id}/content    for every upload
                                            (contentUrl + title required,
                                             always send externalContentId)

4. DELETE /v1/solo-accounts/{id}/content/{externalContentId}
   on every takedown                  ->  fires content_log.deleted

content_log.created and content_log.deleted also arrive as echoes of your own writes, and content_log.deleted additionally fires for removals Easy2257 processes without you.

Four things to get right

1. Register a webhook endpoint before you write a handler. Endpoints live in the partner portal at partner.easy2257.com/webhooks. The callbackUrl you pass to POST /v1/solo-accounts is stored on the record for your reference and subscribes you to nothing. This is the single most common reason a new integration "never receives webhooks".
2. Always send externalContentId on POST. It is optional in the schema but it is the only way to address the depiction later for takedowns. Without it your content is logged but not removable through the API.
3. Wait for solo_account.verified before allowing uploads. The intermediate subscribed_pending_id status means "paid but not yet ID verified": do not unlock content there. The webhook fires only after both payment and ID verification complete, and it carries status: "verified" (the REST API calls the same account "active", so match on event.type, not on the status string).
4. Treat content_log.deleted as authoritative. When Easy2257 fires it, for a creator-initiated removal through the public portal or a request you never saw, pull the content from your CDN within 48 hours per the TAKE IT DOWN Act, even though you did not initiate the takedown.

Creators who already have an Easy2257 account

Some of your creators will already exist on Easy2257, often from another platform. Easy2257 will not hand their identity records to you on your say-so. It emails them and asks them to approve the connection first.

You do not have to detect this case: the provisioning response is deliberately identical to a fresh signup, so your code has exactly two branches (active and everything else) and your integration can never be used to probe whether one of your users has an Easy2257 account.

What changes is the content-logging path. Until the creator approves, POST and DELETE on that account's content return 409:

A third code shares that 409 status on POST only, and it is not a consent state: uploader_not_solo_active means the creator's own Easy2257 account has stopped being active, so there is no verified identity record to attach the depiction to. Retrying does not clear it, however long you wait. Send the creator back through onboarding. Takedowns are deliberately exempt, so DELETE keeps working on an inactive account: a lapsed subscription is not a reason to refuse a removal request.

This is a feature, not a hurdle. It means no partner can quietly attach itself to a creator's compliance record, which is precisely the guarantee that makes creators willing to verify once and carry it across platforms.

Reference

• Quickstart: copy-paste cURL/Node/Python/PHP
• Solo Accounts API: endpoint reference
• Webhook Events: payload shapes
• Webhook Signatures: verification code