HTTP API

Everything your agent can do over MCP is also a plain HTTP endpoint - the same operations, the same response envelope.

Authentication

Send a bearer token in the Authorization header. Two kinds work:

• a personal API token (gtm_…) - create one from the API tokens section in Setup; best for servers and scripts,
• a session JWT - what the web console itself uses after Google sign-in.

export RILO_TOKEN="gtm_..."

Call an operation

Operations are dispatched by id - GET for reads, POST with a JSON body for writes:

# list all operations
curl -s https://your-rilo-host/api/operations/ \
  -H "Authorization: Bearer $RILO_TOKEN"

# a read
curl -s "https://your-rilo-host/api/operations/list_lead_groups/" \
  -H "Authorization: Bearer $RILO_TOKEN"

# a write
curl -s -X POST https://your-rilo-host/api/operations/create_sequence/ \
  -H "Authorization: Bearer $RILO_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "name": "Founder outreach",
    "steps": [
      {"id": "invite", "type": "send_connection_request",
       "message": "Hi {{first_name}}, loved what you are building."}
    ]
  }'

The full operation catalog - parameters, notes, and sample requests - is in the reference.

Responses

Every call returns the standard envelope. ok: true → HTTP 200; failures map not_found → 404, unauthorized → 401, forbidden → 403, and everything else (including validation_error and invalid_signature) → 400:

{
  "ok": true,
  "data": { "…": "…" },
  "summary": "Found 25 person(s) of ~500 matching.",
  "signals": [],
  "learnings": []
}

Ids in responses are always human-readable slugs (e.g. ceo-leads-x7k2); UUIDs are accepted on input everywhere.