Skip to content
ContentRemovalDeskDocumentation

Build your integration

Authorization & protection

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

REST API · JSONv0.2.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. 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.

Explicitly enable the API scan schedule

PUT /v1/creators/{id}/protection with status active requires protection:write and checks current eligibility and available agency API capacity. It starts the active schedule usage interval and enables real scheduled scans.

This is a separate request after enrollment and eligibility. Neither invitation acceptance, a signed or approved mandate, nor a creator.updated event activates scheduling on its own. If your integration wants automatic activation, your backend must decide to send this documented PUT when the latest eligible value is true.

Repeating active for an already active creator does not open another usage interval. The engine checks eligibility again when work runs. Changes to agency ownership, KYC, creator membership, authorization, or entitlement can prevent further execution.

Pause future API scheduling

Use status paused to stop the API schedule, end its usage interval, and cancel queued API scans. Work already dispatched may have real effects and is not rolled back by pausing.

This control does not cancel the creator’s CRD subscription or its independent recurring protection. Manage subscription changes through the existing CRD account workflow.

Resume after a pause or eligibility failure

Resolve the reported account requirement through the existing CRD workflow, then read the creator again. When eligible is true and the agency still wants protection enabled, send the active PUT. Approval alone does not reactivate a paused API schedule.

Pausing does not delete the creator, remove aliases, erase cases, or recall notices already dispatched. Use the current scan and deindex statuses to reconcile work that was already in progress.

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.