activation

Invocation#

echo-cli activation checklists list --product <id>
echo-cli activation checklists add --product <id> --name <text> --step "<title>|<event name>"... --by <name>
echo-cli activation checklists remove --id <checklist-id>
echo-cli activation checklists widget --id <checklist-id>
echo-cli activation progress --checklist <checklist-id> --subject <identifier>

Inputs and output#

checklists list writes the product's checklists by name: id, product_id, name, steps (each title and event_name), created_by, created_at and page_url, the checklist's page for its users on Echo Web; add and remove write the checklist they made or removed. progress writes checklist_id, name, subject, done, total and steps, each with title, event_name and done_at: when its event was first stored for the subject, or null.

State effect#

Every verb calls Echo Web's authenticated /api/analytics/checklists or /api/analytics/checklists/progress with ECHO_INTERNAL_BEARER at ECHO_WEB_BASE_URL; the Activation checklists section of the tracking screen and of Echo Desktop's GEO screen call the same operations, open each checklist's users' page and show its widget snippet, and echo-mcp lists checklists with their page_url (echo_list_checklists), reads progress (echo_checklist_progress) and gives the widget (echo_checklist_widget). --step repeats once per step, in order. A subject is any user id, anonymous id or RevenueCat app user id; progress follows the identity edges recorded at sign-in to every identifier of the same person and reads their stored web and mobile events, so a step done on another device or before signing in counts. Progress is read on every call and never stored. A product links its users to the checklist's page, /checklists/<checklist id> on Echo Web (page_url): a signed-in user sees their own progress there, done steps struck through with when they were done, and a visitor who is not signed in is offered the sign-in that returns to the page. Inside a product, a signed-in user's progress is also read with GET /api/public/checklists/progress?checklist_id=<id>.

Refusals#

• A wrong invocation is refused before anything is sent: "activation takes <every usage, separated by semicolons>; got <words>", "activation <verb> does not take <flag>; it takes …", "<flag> needs a value", "activation <verb> needs <flag>" for each flag the verb needs, "--step takes \"<title>|<event name>\", such as \"Connect a calendar|calendar_connected\"; got <text>" and "activation checklists add needs at least one --step \"<title>|<event name>\"".
• Echo Web answers a bad request with "product_id is required: …", "name is required: …", "steps is required: at least one { title, event_name } the subject completes", "steps[<n>].title is required: what the subject does, in words" (and event_name), "checklist_id is required: …", "subject is required: a user id, anonymous id or RevenueCat app user id" or "created_by is required: an internal caller has no signed-in user, so it names who is acting"; not found with "no product has id <id>; echo-cli products lists the ones that exist", "no checklist has id <id>; echo-cli activation checklists list --product <id> lists them" or "no identity edge names <identifier>; it was never seen at a sign-in"; and a conflict with "product <id> already has the checklist <name> as <id>". The public read answers "sign in to see your checklist: progress belongs to a signed-in user" as unauthorized. The command prints Echo Web's sentence and exits non-zero.
• checklists widget writes { script_url, snippet, script_bytes } after reading the script Echo Web serves at GET /api/public/checklists/widget: the snippet is the <script> tag (data-checklist, and data-subject, the anonymous or user id the product's analytics send) and the <div data-echo-checklist> a product's own page embeds, on its own origin where Echo's sign-in does not reach. The script reads GET /api/public/checklists/subject?checklist_id=<id>&subject=<id> — the subject's progress as progress reads it, answered to a declared origin without a sign-in, as the hints endpoint is — and draws the checklist's name, how many steps are done and each step's title, done or to do, as text. That endpoint answers a bad request with "checklist_id is required: …" or "subject is required: …" and not found with "no checklist has id <id>; …"; the script writes any refusal into the element, or to the console without one.