API keys belonging to the same API account share its lists. OAuth lists belong to the linked user and persist across reconnections. API-key lists and OAuth-user lists are separate workspaces; switching authentication does not transfer a list.
Create a list
Use selected profile usernames from your own lookup or expanded creator results. Saved profiles containplatform and username, rather than creator IDs or scores.
This fictional example illustrates the request:
data. Keep the returned id and version:
id and expected_version. A second create request is a separate list; do not blindly retry a create after an ambiguous network failure. List your saved work and check what was created first.
Reopen and list
SetSHORTLIST_ID to the ID returned by your create request. These commands use jq:
{ "data": [...] }, newest updated first. Saved-work reads require the same owner. A 404 means the list is unavailable to that owner; check the ID and authentication method.
Update with the current version
POST the complete editable list to the same/v1/shortlists endpoint, adding its id and current expected_version. This replaces the editable fields; it is not a partial patch.
version before another change. If another editor has changed the list, the API returns 422 validation_error. Reopen it, review the latest contents, merge your intended changes, and submit that version. Do not automatically overwrite it by fetching a new version and replaying stale content.
Delete deliberately
Deletion permanently removes the list, brief, and notes. It does not delete creator profiles. Ask the user of your application to confirm deletion before sending this request. After reopening the list, sendPOST /v1/shortlists/{id}/delete with { "expected_version": <current version> }. Success returns { "data": { "deleted": true, "id": "..." } }. A stale version returns 422; reopen and confirm again before attempting deletion.