Success action reference
Discover the exact action and granted target, validate input and inspect the plan before execution. Listings can create an identity mirror; widget can emit usage; health and milestone reach can flush pending notifications across the environment. Organization privacy has broader scope than one workspace.
- Get Success overview widget: Return an honest empty overview with four zero metrics, even when Success has customer accounts. When service authentication and organization context are configured, the call attempts an engagement usage event.
- Get Success identity context: Return verified Auth user and optional organization projections without resolving or creating a Success workspace. Canonical workspace discovery and creation remain Auth-owned.
- List Success customer accounts: List all customer accounts in the authorized workspace, ordered by latest update and then name. There is no pagination; the request can create the local workspace identity mirror.
- Create Success customer account: Create a new account in the authorized workspace with initial health 100, healthy status and risk threshold 40 unless specified. Repeated requests create new ids; name is not an idempotency key.
- Record Success account health: Save a score from 0 to 100, append history and enqueue a health-change event on every call, including identical repeats. Downward threshold crossing creates a risk; upward recovery resolves open risks.
- Create Success account milestone: Create a new pending milestone for an account in the authorized workspace, using the account owner as recipient. Creation creates a new id on every call and emits no milestone-reached notification.
- Mark Success milestone reached: Transition a pending milestone to reached in the authorized workspace, stamp reached_at and enqueue its event. Repeating a reached milestone returns 404 rather than a second success.
- List Success playbook tasks: List all tasks for the authorized workspace, ordered by due time and then creation time. Persisted rows include nullable notification and completion timestamps; the request can create the identity mirror.
- Create Success playbook task: Create a pending task for an authorized account with a required ISO due time. Immediate creation does not complete the task or send its due reminder; scheduled processing handles due events later.
- Archive empty Success workspace: Require the exact platform-granted workspace and existing local mirror, refuse any data in six Success content tables, then request canonical Auth archival and remove the local mirror. HTTP 204 has an empty body.
- Export Success organization data: Return all eight local Success stores for the authenticated organization across every workspace, with parsed and sanitized payload fields. Canonical Auth identity, delivered Notify data, provider credentials and backups are excluded.
- Erase Success organization data: Require exact ERASE confirmation, sequentially delete all eight local organization stores and verify zero counts. Auth identity/workspaces, delivered notifications and retained backups remain outside this action.
Evidence
Actual exported Worker responses captured with real local SQLite D1 and all committed migrations, synthetic Auth identity/grants, simulated Notify/Nexus and canonical archive transport. Fixture ids are examples only. No live notification delivery, metering acceptance, privacy erasure, workspace archive or deployment is established by these tests.
Additional action guides
Notification language reads can flush pending messages and require confirmation. These source-reviewed examples are synthetic and unrun; they have different provenance from the earlier fixture captures described above.
- Get notification delivery language: Read or configure only the authenticated human recipient’s notification language in the verified workspace. Stored event copy remains bound to its original release.
- Set notification delivery language: Read or configure only the authenticated human recipient’s notification language in the verified workspace. Stored event copy remains bound to its original release.
Change log
- 2026-10-20: Prepared links to the additional source-reviewed action guides above. Existing guide links and historical evidence are retained; this update does not recertify their current runtime behavior or assert complete application coverage.