Per-step funnel
Enrollment counts plus delivery/open/click buckets per step, and per variant where a step carries an A/B split. Steps are keyed by position label (step 3) so the shape survives tree edits. Defaults to the last 30 days.
bearerAuth writeAuthorizationBearer <token>An API key from the dashboard under Settings → API keys, sent as Authorization: Bearer aem_….
Authorization has two independent axes.
The scope is ranked — a key satisfies any requirement at or below its own tier:
read— see messages, contacts and metrics. Changes nothing, and cannot send.write— everythingreaddoes, plus managing templates, contacts, automations, segments and suppressions. This is what editing a template needs.admin— everythingwritedoes, plus sending configuration: domains, senders, webhook registration, kill switch, daily cap, brand.
There is no approve scope. It was a rung once; it is not one now, and a key requested with it is rejected.
The approval grant (can_approve) is a separate boolean, not a rung. Delivering mail to a real inbox needs write and the grant. Keeping them on separate axes is what makes the review gate a control rather than a convention: a key that may propose is not automatically a key that may approve its own proposal.
Give your application the lowest tier that works. Most need write and the grant — the dashboard mints that combination as Send + manage; Manage only is the same rung with the grant withheld.
Scope: write
id*stringAutomation id or exact name.
since?stringISO 8601 start of the window.
date-timeFunnel.
application/json- response
since?stringdate-timerun_counts?by_step?Keyed by step N.
by_variant?Keyed by step N / variant.
ab_tests?array<>curl -X GET 'https://sendandretain.com/api/v1/automations/string/metrics'{ "since": "2019-08-24T14:15:22Z", "run_counts": {}, "by_step": {}, "by_variant": {}, "ab_tests": [ { "step": "step 1", "leader": "b", "reason": "too_close", "arms": [ { "variant": "string", "delivered": 0, "click_rate_pct": 0, "open_rate_pct": 0 } ] } ]}