Skip to main content
POST
ReadLeadPlaybookAPI mirrors the erdo_read_lead_playbook MCP tool: the

Authorizations

Authorization
string
header
required

An Erdo API key (erdo_api_...) or scoped token (erdo_token_...).

Body

application/json
body
string
required
agent_id
string

Response

Success response

accompanying_email
ReadBackAccompaniment is what the playbook's text says about the email that · object

goes out beside a gated text or call.

Mode is "automatic" (an email may go on its own beside the card) or "never". There is deliberately no "approval": an accompanying email that itself needed approving would be a second thing in front of a person about one lead, which is exactly the shape this engine does not have.

actions
ReadBackAction is one action kind and whether the text lets it run without a · object[]
cadence
ReadBackCadence is how fast the playbook's text says Erdo may work a lead: · object

the per-channel gaps in each reachability state, and how soon after capture the engine may start. It is read out of the text like everything else in the read-back, and then clamped to what the platform allows.

flow
ReadBackFlow is the order a playbook works a lead in, read out of its text so · object

a surface can draw it: each stage's steps in the order they happen, the rules that win from any stage, and the facts about a lead that change which steps happen.

It is a DRAWING, never a guard. The engine decides from the playbook's text; nothing here is enforced and no decision is checked against it. It exists because the rest of the read-back lists the parts of a playbook (stages, actions, a priority ladder) with no arrows between them, and the order is what a reader of the follow-up queue needs to understand why a card says what it says.

Every step, rule and condition carries the passage of the text it was read from, and SourceFound says whether that passage really is in the text. A surface draws an unfound one as unverified rather than as the playbook's.

limits
ReadBackLimit is a restriction the platform imposed on top of the text, so a · object[]
priority
ReadBackPriority is the priority ladder Erdo read out of a playbook: which of · object

the playbook's own rules put a lead at each level, and the factors the playbook forbids taking into account.

The three levels are fixed — high, medium, low. They are the platform's, not the playbook's: the evaluation's response schema constrains the model to exactly those three (see evaluationFormat in evaluate.go) and the queue's sort, its filters and its badges are built on them. A playbook cannot invent a tier; what it decides is which of its rules map onto each level.

NOTHING HERE IS ENFORCED, and this struct is not a guard. The model still chooses a decision's priority and writes its priority_reason, and no decision is rejected, downgraded or rewritten because its priority disagrees with this ladder. The read-back exists so an operator can SEE what Erdo understood — until now the ladder reached the model only as raw playbook text, so a misread rule was invisible until decisions came out wrong. Whether to enforce it is a product decision nobody has taken.

stages
ReadBackStage is one stage the text describes, with the actions it allows · object[]
working_hours
WorkingHours is the window automatic contact is allowed in. Days are · object

lowercase three-letter names; Start and End are "HH:MM" in Timezone.