Your first run

Go from an approved sandbox to a durable result using your server. This is a proposed integration walkthrough; the reserved API origin below intentionally cannot execute a request.

1. Get an approved sandbox

Open the console when the pilot is enabled. Verify your email, create your organization, and submit a pilot application. Provisioning starts only after operator approval. Wait for the sandbox to show Ready. Refreshing the page resumes from durable onboarding state.

Complete MFA, then create the Sandbox server integration key. Copy its secret once into your server's secret manager. The console also provides a stable service actor, workspace, and a no-tools quickstart agent revision. These are resource IDs, not credentials.

Your first key can work in its own workspace, create conversations/runs, manage its files, and inspect its usage. It cannot configure arbitrary agents or tools, impersonate users, or approve writes. Use the console quickstart agent for this first lesson.

2. Create a conversation

Set these variables in your server development environment. Never put a service key into a browser bundle or a shared terminal recording.

export MYSTRO_BASE_URL='https://api.mystro.invalid'
export MYSTRO_TENANT_ID='ten_example'
export MYSTRO_WORKSPACE_ID='wsp_example'
export MYSTRO_AGENT_REVISION_ID='rev_example'
# Set MYSTRO_API_KEY through your secret manager.
export MYSTRO_SCOPE="$MYSTRO_BASE_URL/v1/tenants/$MYSTRO_TENANT_ID/environments/sandbox"

curl --fail-with-body "$MYSTRO_SCOPE/conversations" \
  -H "Authorization: Bearer $MYSTRO_API_KEY" \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: first-conversation-001' \
  --data "{\"workspace_id\":\"$MYSTRO_WORKSPACE_ID\",\"agent_revision_id\":\"$MYSTRO_AGENT_REVISION_ID\"}"

The proposed 201 response wraps the conversation in data and includes request_id. Save data.id in your application. A conversation pins an immutable agent revision.

3. Start work

export MYSTRO_CONVERSATION_ID='conv_example' # Replace with data.id.
curl --fail-with-body "$MYSTRO_SCOPE/conversations/$MYSTRO_CONVERSATION_ID/runs" \
  -H "Authorization: Bearer $MYSTRO_API_KEY" \
  -H 'Content-Type: application/json' \
  -H 'Idempotency-Key: first-run-001' \
  --data '{"input":[{"type":"text","text":"Turn these notes into three next steps: review the backlog, assign owners, confirm Friday delivery."}]}'

A durable admission returns 202, a Location header, and { "data": { "id": "run_example", "status": "queued" }, "request_id": "req_example" } (other resource fields omitted here for clarity). Save the run ID before updating your UI. An HTTP disconnect does not cancel work.

4. Receive the real result

curl --fail-with-body "$MYSTRO_SCOPE/runs/run_example" \
  -H "Authorization: Bearer $MYSTRO_API_KEY"
curl --fail-with-body "$MYSTRO_SCOPE/runs/run_example/events?limit=50" \
  -H "Authorization: Bearer $MYSTRO_API_KEY"
curl --fail-with-body "$MYSTRO_SCOPE/usage" \
  -H "Authorization: Bearer $MYSTRO_API_KEY"

Only a real succeeded run completes onboarding. A queued run, successful login, mock response, or rendered sample does not. Show failures and their request_id honestly. See events and cancellation and server examples.

Next: a useful first-hour workflow

After approval and provisioning, budget roughly 10 minutes for a first run, 20 for deploying and reviewing a public HTTPS ticket tool, and 30 for wiring events and a human approval screen. Tool review and infrastructure provisioning are external prerequisites, not a one-hour promise. Continue with the ticket integration.