Productions

Multi-performer scenes with per-scene consent collection and JWT compliance certificates that any auditor can verify offline.

The Productions flow handles content with more than one performer. It collects per-scene consent from every performer before content goes live and issues a signed RS256 JWT certificate your platform stores alongside the content.

What you get

Per-performer consent collection via magic-link emails. Performers sign on their own device, with no account on your platform required.
A collab_scene.greenlit webhook only after every performer has signed. Gate publication on this signal.
An RS256 JWT compliance certificate per documented production, verifiable offline against easy2257.com/.well-known/jwks.json. Hand it to any auditor with no API call required.
Automatic production.takedown_requested webhooks when a depicted person requests removal, carrying the deadline you have to meet.
Annual re-attestation that issues a new certificate and supersedes the old one. A producer correcting a closed record and reissuing the sealed package does the same thing, so production.documented can arrive more than once for one production.

When to use this vs. Solo Creator

Use Productions for multi-performer content (two-creator collabs, group scenes, full studio shoots). Use Solo Creator for single-performer uploads.

You can integrate both: Solo Creator for ordinary single-performer uploads and Productions for collab content. The same partner API key works for both surfaces.

Two integration flavors

The two flavors use different record types with separate id spaces. A collab scene is created through POST /v1/collab-scenes, and it is the only thing the collab-scene endpoints (/extend, /cancel, /publications) accept. A production is created in the Easy2257 producer UI and contains its own nested scenes — those scene ids look identical (25-character cuids) but belong to a different record type, and passing one to a collab-scene endpoint returns 404. No fee is charged on that 404.

Collab Scenes (UGC pattern)

The uploader on your platform is the producer. Easy2257 sends magic-link emails to each tagged performer, and they consent through Easy2257 with no account on your platform needed. When all signatures land, you receive collab_scene.greenlit and can publish.

1. POST /v1/collab-scenes (uploaderAccountId OR uploaderExternalUserId,
                           title, shootDate, performers[],
                           uploaderAttestation, callbackUrl)
   -> magic-link emails sent to each performer

2. each performer:  visit link  ->  consent + register if new
   -> collab_scene.performer_consented (one per signature)
   -> collab_scene.performer_refused   (any refusal blocks the scene)

3. collab_scene.greenlit webhook  ->  publish content

4. POST /v1/collab-scenes/{id}/publications  for every place you publish

5. (optional) POST /v1/collab-scenes/{id}/extend  to publish on another
   partner platform without re-collecting signatures (collab scenes only)

Scenes expire 14 days after creation. A reminder goes out at day 7, and an expired scene fires collab_scene.blocked with the list of performers who never signed. Size your own follow-up nudges inside that window.

The create body accepts exactly one uploader identifier, uploaderAccountId (the accountId Easy2257 issued at provisioning) or uploaderExternalUserId (your own user id for the uploader), plus title, shootDate, performers, uploaderAttestation, and callbackUrl. Anything else is dropped, and the uploader must resolve to an active solo account under your partner account. There is no idempotency on scene creation: every call creates a new scene, sends new invite emails, and charges a new scene fee, so guard against double submission on your side.

Production Certificates (full-shoot pattern)

For platforms that wrap a full studio production workflow, the producer links the production to your partner account and documents it in Easy2257's UI. When they finalize, you receive production.documented with a JWT certificate.

1. producer links the production to your partner account
   (production page -> Edit -> Partner platform field, pasting your
   Partner ID from the partner portal's Settings page)

2. producer documents the production in Easy2257's UI

3. production.documented webhook  ->  store the certificate alongside content

4. daily GET /v1/productions/revoked-certificates  ->
   if a stored certificate's production appears, revoke / take down

5. (optional) POST /v1/productions/{id}/verify-certificate  for spot checks

Link before documentation completes. The certificate is issued and delivered inside the production.documented webhook at the moment documentation finishes, and every certificate issued from then on is also retrievable any time from GET /v1/productions/{id}/certificates, with its lifecycle status. A production linked after it was documented becomes readable over GET /v1/productions/{id} and starts routing its takedown notices to you; if its certificate predates certificate storage, the list shows the record with jwt null and the certificate itself arrives with whichever comes first: the next annual re-attestation (production.certificate_renewed), or the producer reissuing the sealed package after a correction, which is delivered as production.documented.

Four things to get right

Do not publish before collab_scene.greenlit. A collab_scene.created response means the scene exists, not that consent is collected. Publishing early means you have content from a performer who has not signed.
Budget for the extension fee. POST /v1/collab-scenes/{id}/extend charges your partner owner account $2.00 per extension, off-session against your saved payment method, on top of the original scene fee paid by the uploader. It is the price of not re-collecting signatures, and it is charged per platform you extend to, at most once per scene. The call takes no body: the sceneId the scene owner shares with you is the authorization. Check fee.charged in the response; a failed charge does not revoke the extension, and a re-POST retries the unpaid fee without double-charging.
Store the certificate when it arrives, and fetch it when you need it. The certificate arrives in the production.documented webhook; verify offline against the public JWKS. If you miss or lose one, GET /v1/productions/{id}/certificates lists every certificate for the production with its lifecycle status (CURRENT, SUPERSEDED, REVOKED) and the signed JWT.
Run the revocation sync daily and match on the reason prefix. GET /v1/productions/revoked-certificates returns revoked entries for your productions. Every entry is a takedown signal: neither an annual renewal nor a producer reissue is a revocation, and neither appears. Page with nextCursor, which is an opaque token you pass straight back as cursor, and advance your watermark from the response's retrievedAt field.

Revocation reasons

The reason on each revocation is one of:

Value	Meaning
`removal_request:<id>`	A depicted person's removal request was actioned. Match on the `removal_request:` prefix, because the id varies per request. Take the content down.
`unspecified`	Revoked with no reason recorded. Treat it as a takedown until you confirm otherwise.
`annual_renewal`	Appears only on entries recorded before renewals were split out of this feed (they carry `type: supersession`). The certificate was replaced by the annual re-attestation; the content stays up.

For real-time signals, also subscribe to production.takedown_requested and production.certificate_renewed. The takedown event carries a removalDeadline already computed for the legal basis of the request (48 hours, 72 hours, or 7 business days), so honor that field rather than hardcoding a window.