Agent walkthrough

One real job, end to end: inspect a project, propose a Journey, dry-run it, and hand the result back. Nothing is published or started.

This page shows the raw HTTP loop, for agents you build yourself or run without a browser. An agent in Claude, Codex or Cursor does the same through the hosted MCP server's tools (listed under each step) and needs no token — see the Agent quickstart.

You need a token with read and write only. Leave deliver off.

Base URL

Set it once. Every path below is relative to that value. The responses on this page were captured from a live project; your IDs will differ.

export AUDRYO_API_BASE="https://api.audryo.com/v1"
export AUDRYO_API_KEY="sf_live_..."
export AUDRYO_PROJECT_ID="<project-id>"

MCP: get_manifest, get_bootstrap, get_setup_context, list_journeys, create_journey_proposal, run_dry_run. CLI: npx audryo manifest, bootstrap, setup, journeys list, journeys propose, and the dry-run tool.

1. Discover

Read the manifest before you invent an endpoint.

curl -sS "$AUDRYO_API_BASE/agent_manifest"

You get the operating model, context URLs, and the rule that autonomy levels do not replace explicit user approval for launch. A user can approve in their agent chat; an agent with deliver access can then confirm emails, approve and activate the Journey. This walkthrough uses draft-only access. OpenAPI at $AUDRYO_API_BASE/openapi is the contract if a guide disagrees.

Then see what the token can reach:

curl -sS -H "Authorization: Bearer $AUDRYO_API_KEY" \
  "$AUDRYO_API_BASE/bootstrap"

Copy defaults.projectId into AUDRYO_PROJECT_ID unless you were given one.

2. Understand the project

curl -sS -H "Authorization: Bearer $AUDRYO_API_KEY" \
  "$AUDRYO_API_BASE/projects/$AUDRYO_PROJECT_ID/setup_context"

nextStep is the authoritative first-run action. Do not infer readiness from “a Journey exists.”

Then load audiences you may attach a Journey to:

curl -sS -H "Authorization: Bearer $AUDRYO_API_KEY" \
  "$AUDRYO_API_BASE/projects/$AUDRYO_PROJECT_ID/audience_context"

Also read product_context and data_context before you write copy or pick a goal event. Use the active Foundation revision for product claims and confirmed contact fields for personalization. Foundation revisions activate automatically; unresolved claims are excluded.

3. Propose a Journey

Prefer a template or a specification you designed. Both stay review-only. A 201 is not “this is sending.”

curl -sS -X POST \
  -H "Authorization: Bearer $AUDRYO_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: onboarding-$(date +%Y-%m-%d)" \
  -d '{
    "audienceId": "f671100a-6a85-49dd-aaa5-46022fcd2555",
    "template": "onboarding",
    "name": "Onboarding · first week",
    "goalEvent": "feature_used"
  }' \
  "$AUDRYO_API_BASE/projects/$AUDRYO_PROJECT_ID/workflow_proposals"

MCP: create_journey_proposal with the same fields.

A real 201 looks like this (trimmed):

{
  "id": "c9c43a64-31a6-482d-84bb-fc44cda98240",
  "name": "Onboarding · first week",
  "status": "review",
  "approvalStatus": "pending",
  "version": 1,
  "audienceId": "f671100a-6a85-49dd-aaa5-46022fcd2555",
  "specification": {
    "communicationClass": "marketing",
    "entry": {
      "type": "audience_entry",
      "reentryPolicy": "never"
    },
    "nodes": [
      { "id": "email-1", "type": "email", "label": "Journey email" },
      { "id": "wait-1", "type": "wait_until", "event": "feature_used", "duration": "P2D" },
      { "id": "exit-success", "type": "exit", "label": "Goal reached" },
      { "id": "exit-incomplete", "type": "exit" }
    ]
  }
}

approvalStatus stays pending. Save id as WORKFLOW_ID.

Every email node still needs a confirmed message per enabled locale before anyone can start the Journey. That is a separate step — Emails API or Design emails with your agent. Do not call activate_journey.

4. Dry-run

No mail leaves.

curl -sS -X POST \
  -H "Authorization: Bearer $AUDRYO_API_KEY" \
  "$AUDRYO_API_BASE/projects/$AUDRYO_PROJECT_ID/workflows/$WORKFLOW_ID/dry_run"

MCP: run_dry_run.

{
  "status": "passed",
  "audienceSize": 16,
  "holdout": 2,
  "eligibleRecipients": 14,
  "checks": [
    { "key": "schema", "status": "passed" },
    { "key": "graph", "status": "passed" },
    { "key": "consent", "status": "passed", "detail": "Marketing consent is checked before entry." },
    { "key": "frequency_cap", "status": "passed" },
    { "key": "goal_event", "status": "passed", "detail": "feature_used is confirmed." }
  ],
  "conflicts": []
}

If status is not passed, fix the graph or the data. Do not ask the operator to start it.

5. Hand it back

Stop here. A useful hand-back looks like this:

Proposed Journey "Onboarding · first week" (c9c43a64-…).
Status: review. Approval: pending. Version 1.
Dry-run: passed. Audience 16, holdout 2, eligible 14.
Email node email-1 has no published message yet — that is the next human step.
I did not publish the email, start the Journey, or send anything.

Open the Journey in the app so they can see the canvas: Journeys → the new row. They can click Publish on emails, run Review, and click Start in Audryo. Alternatively, they can review and approve the launch in their agent chat, then authorize an agent with deliver access to perform those steps. Once live, the Journey sends automatically without approval for each delivery.

What you must not do

Related

• Agent quickstart
• MCP, CLI, and skills
• Journeys API
• Journeys