Documentation Index

Fetch the complete documentation index at: https://docs.crewship.ai/llms.txt

Use this file to discover all available pages before exploring further.

​

GDPR — Article 15 access + Article 17 cascade

​

Two endpoints, one audit table

​

Article 15 — exporting a subject’s data

curl -X GET \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "X-Workspace-ID: $WORKSPACE_ID" \
  "https://$CREWSHIP_HOST/api/v1/admin/users/$USER_ID/data" \
  > sar-export-$USER_ID-$(date +%Y%m%d).json

{
  "subject_user_id": "usr_…",
  "exported_at": "2026-05-21T18:42:11Z",
  "scope": {
    "peer_cards": 23,
    "memory_versions": 117,
    "inbox_items": 4,
    "gdpr_actions": 2
  },
  "peer_cards": [ {...}, {...} ],
  "memory_versions": [ {...}, {...} ],
  "inbox_items": [ {...}, {...} ],
  "gdpr_actions": [ {...}, {...} ]
}

​

What’s NOT in the export

• peer_cards — agent-authored peer cards mentioning the subject
• memory_versions — versioned memory blobs the agent wrote about the subject
• inbox_items — inbox rows whose payload references the subject (e.g. persona-suggestion proposals about the subject)
• gdpr_actions — the audit history itself (always included)

• lessons.md entries that mention the subject by user_slug — agents append to a per-crew lessons file with free-form text; the cascade logs a warning naming the subject when its slug is found in any lessons.md but does not modify the file. Operators are responsible for redacting if the lesson text contains personal data. See Lessons memory tier.
• Chat conversation history — the chats table is workspace-scoped not subject-scoped; if the subject’s user_id is user_id on a chat row, the operator filters those rows separately. Covered by Chat sessions retention.
• Audit logs from internal/journal — operator-facing operations the subject performed are tracked in the journal; the operator queries by actor_user_id rather than data_subject_id because the journal is for what the operator did, not what was done to a subject.

​

Article 17 — cascade delete

curl -X DELETE \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "X-Workspace-ID: $WORKSPACE_ID" \
  -H "Content-Type: application/json" \
  -d '{"reason": "GDPR SAR ticket #1234 from data-subject"}' \
  "https://$CREWSHIP_HOST/api/v1/admin/users/$USER_ID/data"

​

What the cascade touches

{
  "action_id": "gdpr_act_…",
  "rows_deleted": {
    "peer_cards": 23,
    "memory_versions": 117,
    "inbox_items": 4
  },
  "warnings": [
    "lessons.md mentions user_slug=pavel_advine — manual review required"
  ]
}

​

Idempotency

• Already-deleted rows are silently skipped (cascade is row-set based, not snapshot-based)
• Each invocation creates a new gdpr_actions row, so the audit trail records BOTH attempts (operators sometimes re-run a cascade weeks after the first attempt to verify completeness — both runs land in the audit)
• The action_id returned in the response is the audit row id, not a transaction id — quoting it back to the operator’s ticketing system gives a stable handle

​

Verifying a cascade landed

curl -X GET \
  -H "Authorization: Bearer $ADMIN_TOKEN" \
  -H "X-Workspace-ID: $WORKSPACE_ID" \
  "https://$CREWSHIP_HOST/api/v1/admin/users/$USER_ID/data"

{
  "subject_user_id": "usr_…",
  "exported_at": "2026-05-21T18:45:30Z",
  "scope": {"peer_cards": 0, "memory_versions": 0, "inbox_items": 0},
  "peer_cards": [],
  "memory_versions": [],
  "inbox_items": []
}

​

Audit table reference

• idx_gdpr_actions_subject (workspace_id, data_subject_id) — fast SAR lookup
• idx_gdpr_actions_initiated (initiated_at) — chronological browse

​

Querying the audit

SELECT id, action, status, initiated_at, completed_at, actor_user_id, reason
FROM gdpr_actions
WHERE workspace_id = ? AND data_subject_id = ?
ORDER BY initiated_at DESC;

SELECT g.id, g.data_subject_id, g.initiated_at, g.completed_at, g.reason
FROM gdpr_actions g
WHERE g.workspace_id = ?
  AND g.action = 'delete'
  AND g.actor_user_id = ?
  AND g.initiated_at > datetime('now','-90 days')
ORDER BY g.initiated_at DESC;

SELECT id, data_subject_id, initiated_at, error
FROM gdpr_actions
WHERE workspace_id = ?
  AND action = 'export'
  AND status = 'failed'
ORDER BY initiated_at DESC;

​

UI surface

1. Lets the admin search a user by email or paste a user_id
2. Exposes two buttons — Export user data (JSON) + Delete user data (cascade)
3. The delete button opens a confirmation dialog with a required reason field + an “I understand this is irreversible” checkbox
4. The dialog stays open during the async DELETE (no auto-close) — a failed call surfaces the error toast without wiping the operator’s input, so they can retry without re-typing

​

What’s NOT exposed

• A self-service deletion endpoint for end users — Article 17 requests are mediated by the operator because the cascade affects content the operator owns (agent decisions, audit records that have to survive operator’s own retention obligations)
• A bulk delete endpoint (“delete every user matching this filter”) — every cascade is one subject at a time, by design, because each gdpr_actions row needs a justification specific to that subject
• Auto-deletion on user account close — closing a Crewship user account doesn’t trigger Article 17 (the user might have other obligations to a different workspace tenant within the same Crewship instance); the explicit cascade endpoint is the only path

​

Cross-references

• Threat model — Tenant isolation on internal-auth handlers — how the GDPR cascade endpoints fit into Crewship’s tenant-isolation surface area
• Audit logging — broader audit log shape; gdpr_actions is a specialized table for the GDPR cascade subset
• Encryption at rest — operator-side encryption that protects gdpr_actions rows in backups + filesystem snapshots
• Agent memory — peer cards — how peer cards get created and what data_subject_id they end up with
• Admin API — schemas for the two endpoints