Build your integration
Creators & aliases
Read and update the same creator roster used in your CRD agency dashboard, or invite a new creator through existing onboarding.
On this page
Link an existing creator or invite a new one
POST /v1/creators requires workspace_id, your stable external_id, and display_name. Read the roster first and reuse an existing API creator ID. When linking by CRD identity, include crd_user_id. The profile must belong to the bound agency and must not be a staff account.
For a new creator, omit crd_user_id and provide email, first_name, last_name, and optional locale (en or fr). The invitation uses CRD’s existing onboarding flow and sends real email. It does not fabricate a signed mandate, approved identity, or subscription.
Names, aliases, and official URLs
Names, aliases, and supported profiles connect to the same creator identity used by CRD. Added URLs are unverified profile data; supplying a URL does not verify ownership. Several aliases or URLs remain one creator profile. Stored aliases may be up to 160 characters, but the current scan variant builder uses aliases of 2–60 characters containing a Latin letter and selects up to two extra variants per handle.
Unknown fields are rejected. There is no media upload endpoint. Do not include passwords, session cookies, private messages, photos, or voice files in the payload.
| Field | Rules |
|---|---|
| external_id | Your stable ID, 1–200 characters; unique within the workspace. |
| display_name | Creator display name, 1–160 characters. |
| aliases | Up to 30 names or usernames, at most 160 characters each. |
| profile_urls | Up to 20 supported official HTTPS profile URLs, at most 2,048 characters each. |
| crd_user_id | Existing CRD creator UUID, or use the invitation fields instead. |
| email / first_name / last_name | Required for an invitation when crd_user_id is absent; email ≤254 characters and each name ≤100. |
| locale | Optional en or fr for the invitation flow. |
Update the same creator from your backend
PATCH /v1/creators/{id} accepts a non-empty subset of display_name, aliases, and profile_urls. It writes to the linked creator’s actual CRD identity, so the agency dashboard and later API reads see the change.
Omitted fields remain unchanged. Aliases and official profiles merge into the existing collections; they do not remove other entries. Use PATCH for identity changes rather than resubmitting enrollment with changed fields.
Keep your enrollment request stable
Use the same external_id and complete payload when retrying an uncertain enrollment. A matching existing enrollment returns the same creator; changed fields return external_id_conflict. Enrollment is not a profile update endpoint.
If the roster already imported the same CRD user, enrollment reuses its stable API creator ID and can assign your external ID once. It does not create a duplicate profile. Read GET /v1/creators/{id} for current linkage and eligibility; identity_sync_pending means submitted identity data still awaits legal onboarding. Creating an invitation or API creator record alone does not make the creator eligible for a scan.
Activate several creators with one reviewed total
Enrollment and scans still use individual requests. For active_creators billing, select 1–50 eligible inactive creator IDs and POST /v1/protection/bulk/quote with creator_ids. Show the returned quantity, unit_price_cents and monthly_total_cents to the owner; this is the total for the entire resulting active roster.
After approval, PUT /v1/protection/bulk with creator_ids, expected_price_cents and expected_quantity, using a saved UUID Idempotency-Key. A 202 checkout response is pending. Complete checkout, then read the creators to confirm active status. Retry the exact operation after uncertainty. Only one billing change can be pending per agency.
The subscription quantity is shared, but protection is individual. PUT /v1/creators/{id}/protection can pause one creator without pausing the others. Bulk activation checks all selected creators and records them separately; an invalid selection is not partially activated.
Read the creator’s current state
Read billing.model, billing.unit_price_cents, billing.activated, authorization, entitlement and eligible. With active_creators, a creator can have approved authorization but remain ineligible until activation checkout succeeds.
protection_status reflects the last observed dispatch state. Portal and API changes synchronize on reads and worker reconciliation; webhooks report observed changes, not every intermediate database edit.
Turn creator state into a clear next action
Eligibility can change after activation. Read current state when an operation is rejected, rather than treating a previously approved creator as permanently eligible. A transferred or archived creator may no longer be accessible to the original agency.
| Observed state | Integration action |
|---|---|
| No crd_user_id; enrollment_status indicates an invitation | Show that acceptance/onboarding is pending. Poll the creator or refresh after creator.updated. |
| Linked; identity_sync_pending: true | Some submitted identity data awaits completion of the existing signed legal onboarding. Keep the same creator ID. |
| authorization.approved: false | Show authorization required or under review. The creator and CRD use the existing portal signing/review process. |
| entitlement.active: false | Resolve the existing account or agency entitlement through CRD; the API does not purchase a subscription. |
| eligible: true; protection_status: not_activated or paused | Send the explicit active PUT if the agency wants API protection enabled. |
| eligible: true; protection_status: active | Follow scheduled work or request a manual scan with a stable Idempotency-Key. |
| Enrollment failed or uncertain | Inspect the returned error and reconcile the same external_id and original payload before retrying. |
Request & response example
/v1/creatorscurl --request GET 'https://api.crd.systems/v1/creators?limit=25' \
--header "Authorization: Bearer $CRD_API_KEY"{
"data": [
{
"id": "crt_example",
"workspace_id": "wsp_example",
"external_id": "creator_001",
"display_name": "Example Creator",
"aliases": [
"example_creator"
],
"profile_urls": [
"https://onlyfans.com/example_creator"
],
"protection_status": "not_activated",
"created_at": 1790035200000,
"enrollment_status": "linked",
"crd_user_id": "33333333-3333-4333-8333-333333333333",
"invitation_id": null,
"simulated": false,
"scan_schedule_managed_by": "api",
"crd_subscription_managed_by": "crd",
"identity_sync_pending": false,
"authorization": {
"approved": true,
"status": "approved",
"expires_at": null
},
"entitlement": {
"active": true,
"source": "agency_subscription"
},
"eligible": true
}
],
"next_cursor": null
}Illustrative response. Replace example resource IDs with the IDs returned by your API requests. View endpoint details.
Use complete profile URLs
The API and ordinary creator form use shared profile-link rules and write to the same native creator records. Send the full canonical HTTPS profile URL, not a bare username or a post. Use aliases for pseudonyms and alternate usernames. A supplied URL is not proof of ownership.
The supported portal platforms are OnlyFans, MYM, Fansly, Stripchat, Chaturbate, ManyVids, Fanfix, Fanspicy, Fanblast, RevealMe, Uncove, Patreon, Passes, Pornhub, Playboy, Instagram, TikTok, X, Snapchat, Facebook, Reddit, Telegram, Discord, YouTube, Twitch and Website. Legacy API hosts remain accepted. Unknown public HTTPS hosts are stored as Website records; they do not create new social-platform integrations.
No tracking query, fragment, embedded credentials, private address or login/post URL. Structured profile URLs such as ManyVids and YouTube channel IDs retain their complete path. Send aliases separately when the handle is not apparent from that path.