# Team workspaces, summary categories and lifecycle events

Updated 2026-10-09. These are CreatorAPI service features for connected OnlyFans and Fansly accounts, subject to each account's existing platform, slot, permission and credit checks. They do not imply complete parity with another provider.

## Independent team sign-ins

Open [Team workspace](/team). Owners can use an existing dashboard sign-in or sign in with email and password. Each employee uses their own identity; never share the owner's password or API key. Only a verified, active owner with a full-scope workspace key can enable team administration.

Invitations create a single-use link, not an email. Copy and share it yourself. Links expire in 1–168 hours (default 48); 20 invitations per actor per hour and 100 pending per workspace. The token is stored hashed and placed in the URL fragment, not an HTTP query. New employees get no API key, trial credits or payment access. Existing customers must sign in with the invited address and verify their existing account. Accepting an invitation never replaces their password or personal workspace.

| Method | Path | Purpose |
| --- | --- | --- |
| POST | /v1/auth/team-login | Email/password sign-in; secure HttpOnly cookie |
| POST | /v1/auth/team-session | Convert a dashboard bearer session into a one-day cookie |
| POST | /v1/auth/team-logout | Revoke the session and remove the cookie |
| GET | /v1/auth/workspaces | Available workspaces, selection and effective permissions |
| POST | /v1/auth/workspaces/select | Select workspace_key_id |
| GET | /v1/team/permissions | Supported granular permissions and role defaults |
| GET | /v1/team/members | Members and effective permissions |
| PATCH | /v1/team/members/{user_id} | role and optional extra_permissions |
| DELETE | /v1/team/members/{user_id} | Revoke membership; does not delete the identity |
| GET, POST | /v1/team/invites | List or create invitations |
| DELETE | /v1/team/invites/{invite_id} | Revoke an unused invitation |
| POST | /v1/team/invites/inspect | Inspect a token without disclosing the full invited address |
| POST | /v1/team/invites/accept | Accept with token and, for a new identity, name/password |
| GET | /v1/team/audit | Recent team actions, limit 1–500 |

Invitation creation body:

```json
{"email":"employee@example.test","role":"viewer","expires_in_hours":48,"extra_permissions":[]}
```

Team endpoints require a human dashboard session, not a raw API key. MCP-scoped sessions cannot select or administer a workspace. Cookie writes and the login/session/accept endpoints require the same Origin as the CreatorAPI website/API. Team sign-in returns no bearer token in JSON. A one-day cookie is Secure, HttpOnly and SameSite=Strict.

## Roles and permission boundaries

Viewer reads supported creator data but cannot generate a fresh summary or create/download exports. Operator/member can operate supported creator-data features. Developer can read data and manage exports/webhooks. Admin can manage non-admin members; only the owner can assign or manage administrators. Custom starts empty. Extra permissions are additive to role defaults. Non-owners cannot grant permissions beyond their own or delegate team-administration permissions.

Permission families include accounts, native data, fans, analytics, media, Smart Links, pixels, postbacks, webhooks, data-export, summary-categories and team.members. Use the permission catalog for exact supported names. Some names reserve future surfaces; unmapped or unimplemented endpoints are not enabled by a permission name.

Revocation and role changes apply on the next request. Unknown staff routes are denied before billing. Owner keys, payments, billing administration, creator connection and global administration remain unavailable to staff. Team audit records contain no invitation tokens. Export metadata reads do not issue download URLs to members lacking data-export.manage. Previously issued bearer download URLs retain their documented expiry; treat them as secrets.

## Workspace summary categories

Both /v1/fan-summary-categories and /api/fan-summary-categories support GET and POST. PUT and DELETE use /{category_id}. POST/PUT require label and keywords; write access requires a full-scope key and, for staff, summary-categories.manage. Reads require summary-categories.view. These configuration calls are free.

```bash
curl -X POST https://api.creator-api.com/v1/fan-summary-categories \
  -H "X-API-Key: YOUR_KEY" -H "Content-Type: application/json" \
  -d '{"label":"Gift preferences","keywords":"gift, wishlist, book"}'
```

GET/POST/PUT return {"data": ...}; DELETE returns deleted and id. A category has id, immutable key, label, keywords and created_at. At most 10 categories per workspace; labels are 1–100 characters and keywords a comma-separated string of 1–20 distinct terms, each at most 80 characters (1,000 characters total). Invalid input returns 422, duplicate keys/capacity 409 and foreign/missing IDs 404. JSON bodies are limited to 8 KiB.

GET /v1/{account}/fans/{fan_id}/summary uses the calling workspace's categories and cache. A cached result is free; a cache miss or refresh=true requires fan-profile-summary.generate in addition to view access and follows the existing 25-credit admission. Category changes invalidate that workspace's cache. Legacy account-global caches are not reused across workspaces.

With custom categories, retrieval scans at most 500 messages and includes the recent 80 plus at most 120 older keyword-matching fan messages. Custom values are short strings or null when evidence is absent. Labels, keywords and transcripts are untrusted data, not model instructions. history_coverage, when present, describes provider pagination; history_messages_scanned and history_scan_limit describe bounded retrieval, never proof of an unlimited complete history. A generation_id identifies each new result. A timeout may finish into the cache later; the timed-out request is refunded under the existing billing policy.

## Durable lifecycle webhooks

Create a webhook with POST /v1/{account}/webhooks using the key of the workspace whose jobs/results you want. Ownership comes from authentication, never from an owner_key_id supplied in the body. Existing ownerless hooks keep their existing platform-event behavior but do not automatically receive these workspace-specific events. Create a new owned hook to subscribe.

- data_exports.in_progress: a new export attempt started.
- data_exports.completed: the attempt produced its downloadable result.
- data_exports.failed: the attempt failed.
- data_exports.cancelled: the attempt was cancelled.
- fan_summary.completed: a new summary, not a cache read, completed.

Export data contains id, dataset, fmt, status, attempt, row_count and status_path. It contains no file paths, download secrets, workspace key IDs or provider exception text. Retry increments attempt; a still-stopping worker returns 409. Retry preserves the original job/reservation policy and does not charge again.

Summary data contains fan_id, generation_id, status, summary, model, message_count, generated_at and history_messages_scanned. It includes the generated brief, which may contain sensitive fan information; it does not include the whole source transcript. There is no fan_summary.failed event in this release.

Source state and outbox rows commit together. A 30-second reconciler retries transfer into the existing webhook delivery queue. Stable event IDs and transactional receipts avoid duplicate enqueueing after a transfer crash. Only active matching workspace/account hooks created before the event qualify. No historical backfill is implied. Pending outbox entries are retained until transferred; receipts/outbox history currently have no automatic purge.

Consumer delivery uses the existing signed retry queue and its retry/age limits. Delivery is at least once, not exactly once: deduplicate by envelope id and hook. Verify X-CreatorAPI-Signature as sha256= plus HMAC-SHA256 of the exact raw request bytes with the webhook secret. Do not reserialize JSON before checking it. Paused/deleted hooks and expired retry budgets follow existing queue behavior; delivery to every consumer is not guaranteed.

## Verification boundary

Workspace, category, worker-race, transactional rollback, queue and signature checks run with real isolated storage/API/HTTP/browser behavior and synthetic provider/model responses. These results are separate from previously documented live OnlyFans/Fansly reads. No new message, purchase, subscription, customer invitation email or provider mutation is required for this release. Full platform-event parity, media-upload lifecycle events, private partner integrations and a proven SEO/lead-decline cause are not claimed.