Skip to content
ContentRemovalDeskDocumentation

Build your integration

Authorization & protection

Use the creator’s actual CRD authorization and entitlement before enabling API protection.

REST API · JSONv0.8.0 · Live CRD integration
On this page

Agency verification is separate from creator authority

Agency KYC verifies the agency account before API access. Each creator must separately complete CRD onboarding and have an approved, signed, unexpired mandate and active entitlement. Agency approval does not automatically authorize action for every creator.

Read actual eligibility

GET /v1/creators/{id} reads the linked creator’s actual CRD state. Inspect authorization, entitlement, and eligible before activation. A pending invitation must be accepted and onboarding completed first.

Mandates are handled through CRD’s existing creator authorization flow. There is no public API operation to sign or approve one. A text evidence reference cannot replace the actual mandate.

The creator signs in the existing CRD portal

For a newly invited creator, CRD sends its existing branded invitation email. After acceptance, the account joins the agency and opens the creator dashboard. The existing dashboard asks for any missing official accounts and presents the DMCA authorization signing flow. CRD reviews that submission through its existing approval process. Agency creators use the existing in-app approval notification and observed creator.updated state; do not wait for a separate standard creator approval email.

Your integration can show an Awaiting authorization state while polling GET /v1/creators/{id}, or refresh the creator after a creator.updated webhook. For active_creators, wait for authorization.approved before requesting a paid activation; wait for eligible before scanning. For legacy agreements, continue when eligible becomes true. If the creator already belongs to the agency and has a valid approved authorization and entitlement, reuse that existing state; no second signature is required by the API.

The API enrollment response includes invitation_id and email_sent, not the private invitation link. There is no API-only substitute for the creator’s signature. The integration observes enrollment, authorization, and entitlement changes through creator reads and creator.updated events; there is no separate mandate-approval endpoint.

Activate protection and confirm billing

Read creator.billing.model. For active_creators, PUT /v1/creators/{id}/protection changes the same paid activation as the agency portal. Supply status active, expected_price_cents from creator.billing, and a stable UUID Idempotency-Key. An approved mandate, signed agency agreement and completed onboarding are required; eligible may be false before the first paid activation.

First activation returns 202 with checkout_url. The owner completes checkout to start one seven-day trial per agency. Further paid activations are charged immediately at a prorated amount. Do not display active until a subsequent creator read confirms it. Retry uncertain outcomes with exactly the same key and payload.

For legacy agreements, this endpoint retains its API-dispatch-only behavior and does not change the subscription. Existing rates and capacity stay intact.

Pause protection

For active_creators, submit status paused with the confirmed expected_price_cents and a stable UUID Idempotency-Key. Confirmation stops new protection work and reduces the billable quantity. Unused paid time becomes credit toward the next invoice after the current invoice is paid; no automatic bank refund is made.

Already-delivered notices cannot be recalled. Case history remains available. Pause before removing or transferring a creator. For legacy agreements, pausing here only stops API dispatch.

Resolve a pending change

Only one billing operation per agency may be pending. Resume it using the same key and body, or use /agency/billing. An open checkout can be cancelled there. Do not create another operation to bypass a timeout.

Mandate and payment failures block execution. Restoring eligibility does not itself start a new billable activation.

Request & response example

GET/v1/creators/{id}
curl --request GET 'https://api.crd.systems/v1/creators/crt_example' \
  --header "Authorization: Bearer $CRD_API_KEY"
Use your secret key in the environment variable.
Example response · 200
{
  "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
}

Illustrative response. Replace example resource IDs with the IDs returned by your API requests. View endpoint details.