Every declared onboarding step, with whether it is already done
const url = 'http://localhost:11044/api/v1/next-steps';const options = {method: 'GET', headers: {'X-Embabel-Api-Key': '<X-Embabel-Api-Key>'}};
try { const response = await fetch(url, options); const data = await response.json(); console.log(data);} catch (error) { console.error(error);}curl --request GET \ --url http://localhost:11044/api/v1/next-steps \ --header 'X-Embabel-Api-Key: <X-Embabel-Api-Key>'status is DONE, TODO or UNKNOWN. UNKNOWN means the step’s own query could not be answered — detail says why — and must not be shown as outstanding work: a surface that nags on a broken query nags hardest when the appliance is least well.
Authorizations
Section titled “Authorizations”Parameters
Section titled “Parameters”Query Parameters
Section titled “Query Parameters”Username whose world is read; when it names an existing user it is used even if the request is authenticated as someone else. Omitted, blank or unknown, the authenticated user is used; 401 when neither resolves to a user
Responses
Section titled “Responses”OK
Every declared onboarding step, done ones included. Which to show and in what order is the client’s decision
object
The steps, in declaration order
One onboarding step and the answer to its own question
object
Why the status is UNKNOWN, in the step author’s words; null otherwise
The user said they will not do this step. Orthogonal to status: a dismissed step that gets done still reports DONE
The step’s id, as the dismiss endpoint names it
Everything else the step’s YAML declared, carried through uninterpreted: a console reads a route from it, a chat surface an input. Open by contract
object
DONE, TODO, or UNKNOWN when the step’s query could not be answered — which must not be shown as outstanding work
Example
{ "steps": [ { "status": "DONE" } ]}
