hello everyone! seems like I am going to be the one to post the first API request here 🚀 • to have step info in reply_categorization webhook events, now we provide only sequence ID for this webhook

Potential Bug with

emailTemplateId

. API returns a 400 demanding

subject

and

message

- even though according to the new API docs both should be ignored when

emailTemplateId

is provided. We have a customer trying to create email sequence steps with PDF attachments via API V3. The expected workflow based on the docs is: • upload attachment • create email template with that attachment • create a sequence step referencing the template via

variants.emailTemplateId

. The issue:

emailTemplateId

does not work. When provided, the API returns a 400 demanding

subject

and

message

Based on my tests. when those are provided - the step is created with the content of the

subject

and `message`completely ignoring the template and skipping the attachment.

POST /v3/sequences/1678728/steps

{
  "type": "Email",
  "delayInMinutes": 0,
  "executionMode": "Automatic",
  "variants": [{ "emailTemplateId": 242978 }]
}

{
  "status": 400,
  "title": "Validation failed",
  "detail": "The request body contains validation errors.",
  "extensions": {
    "errors": [
      "Email template message is required.",
      "Email template subject is required."
    ]
  }
}

The workaround with using the emailTemplateId with the V2 calls (Create Campaign (Template Step Text) and Add Step to Campaign) seems to be working as expected and Steps are created with the template content and attachments.

Hey 👋 Working through the Reply API for a 100+ sequence client buildout. One gap I can’t crack: ✅ Working: PDF on a step at creation time via POST /v2/campaigns with steps[].templates[].emailTemplateId (template has attachmentIds set). UI shows it, sends deliver with the PDF attached. ❌ What I need but can’t find: a way to add a PDF to a step in a sequence that already exists. Things I’ve already tested and confirmed don’t work: • PATCH /v2/campaigns/{id}/steps/{stepId} with attachmentsIds: [id] — accepted, silently persists [] • PATCH setting emailTemplateId post-creation — pulls subject + body from the template, but not the attachment • All v3 step variant attachment fields (attachmentIds, attachments, fileIds, templateAttachmentIds) — silently dropped • save-as-template → create-from-template — strips attachments on clone • Every plausible hidden endpoint I could think of (/v3/sequences/{id}/steps/{step_id}/attachments and variants) — 404 Has anyone found a working API path — documented, undocumented, or via a workflow tool — to attach a file to a step in an already-created sequence? Or is rebuild-from-scratch the only option today? Cheers 🙏

Hi there! The request to have the following fields consistently available and populated across all webhooks/events (email sent, email opened, link clicked, etc): • sequence_id • sequence_name • email from

Hey team! I’ve prepared the first portion of the feedback on v3. Please check it and let me know if it makes sense 🙌

Feature request: Webhook for every inbound reply (not just the first) Currently

email_replied

and

linkedin_message_replied

only fire on the first reply from a contact in a sequence. After that first event, any follow-up messages in the same thread are silent. Requested: A new webhook event (or an option on the existing ones) that fires on every inbound reply from a prospect in the same sequence/thread - second, third, and beyond. Why: Our customer is building automations that need to react to each response in a conversation, not just the initial one. Right now there's no way to get notified programmatically when a prospect sends a follow-up message.

Hi! The request is to include a secondary category in the webhook payload when there are two or more inbox categories. For example, modify the existing webhook by adding a new property such as:

"reply_inbox_meeting_intent": true/false

Messages in this channel may be stored by a third-party help desk service.

Hi! Any plans for an organizations API to programmatically create new workspaces?

Feature request — API / MCP connector: support setting a contact's status to "Meeting booked" Today we can mark a contact as Replied via the API and the MCP connector, but there's no way to set "Meeting booked" (or update contact status generally) programmatically — it can only be done by hand in the UI. Since we book meetings through outbound, we'd like to keep the "Meetings booked" metric and contact statuses accurate automatically rather than updating each contact manually. Could you add an endpoint / MCP tool — e.g. update_contact_status (or mark_contacts_as_meeting_booked) — that accepts prospect IDs or emails plus a target status? Ideally exposed on the v3 API and surfaced through the MCP connector so agent-driven workflows can flag contacts the moment a meeting is confirmed. That would close the gap with the existing "mark as replied" action and keep our reporting and CRM sync clean.

Hi @Max Foster, as discussed, here are my requirement for future use of reply.io API:

Reply.io API — Requirements for Autonomous, Multi-Client Reporting From: Aexus Goal: Run the entire back office (weekly client reporting) for ~100 clients as a fully automated workflow, driven by an AI agent. The agent ingests each client's outreach activity from Reply, categorises it, builds the client report, and writes status back — with no human in the loop except review. Context we've already verified in your v3 docs (credit where due): The v3 REST API is genuinely close. You already ship (in Beta): a Reports API (email/call/LinkedIn/task overviews,

list email/call activity

,

list meetings

), the Inbox API (

list inbox threads

,

list messages in an inbox thread

, categories, meeting-intent),

get activities for a contact

, contact

update

with `meetingStatus`/`callStatus`/`isOptedOut`, full Tasks CRUD, and Webhooks (subscriptions + event catalog + delivery logs). The gaps below are therefore mostly expose / stabilise / scale, not "build from scratch." 1. The #1 blocker: surface v3 in the MCP connector Our agent talks to Reply only through the Reply MCP connector, not raw REST (the agent cannot make arbitrary authenticated HTTP calls). Today the connector exposes ~15 tools — essentially sequences, basic stats,

mark_contacts_as_replied

,

add_contact_to_sequence

, and

connect_*

helpers. None of the rich v3 surface above is reachable. Ask: Expose the following v3 endpoints as MCP tools (read + write): • Inbox:

list/filter inbox threads

,

list messages in an inbox thread

, thread categories,

toggle meeting-intent

. • Reports:

get email/call reporting overview

,

list email activity

,

list call activity

,

list meetings

. • Contacts:

get/search contacts

,

get activities for a contact

,

update a contact

(incl.

meetingStatus

,

callStatus

,

isOptedOut

). • Webhooks: create/list/update subscriptions. Without this, every read still requires manual copy-paste (today we paste reply text and screenshot the stats dashboard by hand). 2. De-Beta: a stable, versioned contract Every endpoint we need is flagged "Beta — behavior, parameters and response shapes may change without notice." A production back-office for 100 clients cannot build on that. Ask: Promote the Reports, Inbox, Contacts, Tasks and Webhooks endpoints to GA with a stable, versioned schema and a published deprecation policy. 3. Reads — the report inputs 3a. Inbound reply content + normalised category (biggest manual step today)

list messages in an inbox thread

should return, per message: full body text, subject, sender, direction, timestamp, the canonical contact id + email, and the sequence/client. Add: a normalised reply-category / intent field per thread (e.g.

interested

,

not_interested

,

out_of_office

,

referral/redirect

,

wrong_contact

,

meeting_request

,

opt_out

) so we don't re-derive it. Make threads filterable by sequence/client, date range, and "unprocessed since X." 3b. Stats as data (so we stop screenshotting the dashboard)

get email reporting overview

should return the full funnel as numbers — Total/Contacted, Delivered, Open, Reply, Interested, Meetings booked, Opt-outs, Bounce, Not reached — PLUS the per-sequence breakdown and a daily/weekly time series, all filterable by sequence group / client and date range. Today we paste a screenshot of this exact view; structured data lets us render it ourselves. 3c. Call activity with normalised dispositions

list call activity

should return per call: contact id+email, datetime, normalised disposition (

connected

,

no_answer

,

voicemail

,

wrong_number

,

not_interested

,

callback_requested

,

meeting_booked

,

opt_out

), free-text note, attempt number, agent. Today these come from external Ringover/Excel exports; if calls flow through Reply, this endpoint removes that dependency. (Disposition normalisation matters — our manual data has 6+ spellings of "wrong number"/"not reached.") 3d. Meetings with full lifecycle

list meetings

should include: contact, company, datetime, status lifecycle (

booked → held → no_show → rescheduled → cancelled

), attendees, sequence/client, source. Our "Meeting Tracker" is cumulative and needs the lifecycle, not a boolean. 3e. Unified "what changed since" feed (the dedup engine) The single hardest part of weekly reporting is dedup — not re-reporting a prospect already covered, especially in re-engagement campaigns that re-hit prior contacts. Ask: a per-client/sequence activity stream filterable by date range that unifies replies, calls, meetings, opt-outs, and status changes, each stamped with a timestamp and the canonical contact id. ("Give me everything new for Client X between A and B.") This single capability eliminates ~90% of our manual dedup work. 4. Writes — status back to Reply • Bulk + by-email status setters. Today

update a contact

is single-contact, by numeric

id

. We identify contacts by email and act in batches. Provide bulk setters that take a list of ids or emails (mirroring `mark_contacts_as_replied`'s

prospectIds[]

) for

meetingStatus

,

callStatus

,

isOptedOut

. • Richer

meetingStatus

. Currently binary (

none

/

meetingBooked

). Extend to the lifecycle in 3d (

held

,

no_show

,

rescheduled

,

cancelled

) so the write-back matches the Meeting Tracker. 5. Scale & multi-tenancy (100 clients) • First-class "client / workspace" grouping. Today we infer a client by sequence-name prefix (e.g.

Atlas_MW_*

,

S4U_*

). At 100 clients this is brittle. Provide a native client/workspace (or tag/folder) entity that groups sequences + contacts + inbox + stats + calls, and make every reporting endpoint filterable by it. • List all clients/workspaces + per-client scoping in one call. • Multi-tenant auth. One managed credential that can act across all client workspaces (or clean centralised per-client key management) — not 100 separate keys pasted around. • Pagination, bulk, and rate limits sized for a nightly/weekly run across 100 clients (cursor pagination is there; confirm bulk read endpoints and rate-limit headroom for full-portfolio sweeps). 6. Reliability & identity • Webhook coverage + reliability. Confirm the event catalog covers: reply received (with category), opt-out, meeting booked/updated, call logged (with disposition), bounce, and contact status change — with full payloads, delivery logs, and retry. Webhooks + the §3e activity feed are the real-time backbone of an autonomous loop. • Canonical contact id everywhere. Surface the same stable contact id (and email) on every inbox message, call, meeting, and activity, so dedup is keyed on id — never on name spelling (we routinely hit "Müller" vs "Mueller", "Höschele" vs "Hoeschele"). Definition of done — the autonomous loop we want to run For each client, on a schedule, with no human in the loop: 1. Pull the period's new activity (replies + calls + meetings + opt-outs) via the §3e feed/webhooks, scoped to that client. 2. Read reply bodies + categories, call dispositions, and meeting lifecycle (§3a/3c/3d). 3. Dedup against what was already reported, keyed on canonical contact id (§3e/§6). 4. Pull funnel + per-sequence stats as data (§3b) and render the visual. 5. Build the client report. 6. Write back statuses in bulk — meeting booked/held, opt-outs, replied (§4). 7. Human reviews the finished reports and the flagged judgment calls. Everything above already half-exists in v3. Exposing it in the MCP connector, stabilising it out of Beta, adding a client/workspace dimension, and normalising the reply/call/meeting fields would let us run the whole thing autonomously.

Good — that's already the safe default in the enroll path: a contact already in another sequence returns

IN_OTHER_SEQ

and is left where it is (never force-moved into Cequence), and opted-out contacts are skipped too. Let me confirm the running enroll is behaving that way and see the status spread so far: Checked enroll status tally + whether IN_OTHER_SEQ are skipped Wait — your instruction surfaces a real risk I need to handle immediately. The custom fields (

Personalisation

,

Job Posting

, etc.) are account-level and shared across sequences. The running enroll imports with

overwriteExisting=True

, so any of these 377 who are active in another sequence (e.g. VDL) would have their shared fields overwritten with Cequence content — corrupting their other sequence's emails. I'm stopping the enroll now before it does more of that: Stopped. Now I need to assess the blast radius before doing anything else. The

enroll_csv

runs the bulk import (overwrite=True) first, then the enroll loop — so the import may have already overwritten fields. The real exposure is only contacts active in another sequence that reuses these shared fields. Let me check: did the import overwrite all 377, and are the touched contacts in other active sequences? Assessed overwrite extent + sequence membership of touched contacts All 7 checked show

sequences=[]

and — notably — Personalisation does not match the Cequence content, suggesting the overwrite may not have taken. But gotcha #17 warns the

sequences

field reads

[]

for paused sequences, so I can't trust it blindly. Let me verify its reliability against a known active-VDL contact, and check the real overwrite state of the sample: Tested sequences-field reliability + sample overwrite state Two key facts: (1) the

.sequences

field is unreliable — a known active VDL contact also shows

[]

, so I can't use it; (2) the import did overwrite the sample (the

None

ids fooled my earlier check, but the values are clearly Cequence content). So I need the authoritative cross-reference. Let me first quantify the damage (did the stopped enroll's bulk-import overwrite all 377?) and scope the active sequences: Damaged check + active-sequence scope This is a real problem I need to own. The bulk import overwrote all 377 contacts' shared account-level fields, and there are 83 active sequences (Affix, Flotiq, Aexus, Simreka, S4U…) all using the same canonical container fields. Any of my 377 who are active in those would have had their other campaign's personalization clobbered. I have to quantify the overlap authoritatively (the

.sequences

field is broken). Let me cross-reference my 377 against every active sequence's enrolled contacts:

Are these types of problems sovled if i swap to agency plan?

added an integration to this channel: linen-selfhosted

added an integration to this channel: linen-selfhosted

added an integration to this channel: reply-community-mirror

Hiya, how come its still not possible for mcp or api to leave email steps subject line empty?

added an integration to this channel: reply-community-mirror

added an integration to this channel: reply-community-mirror

added an integration to this channel: reply-community-mirror

is there any plan to allow API calls in sequences outside of zapier?

Are Organization Admin's supposed to be able to buy new LinkedIn accounts within any workspace?

Pulled the full 30-gotcha ledger. Here’s the honest answer: I’m already operational in Reply.io, but “world class” is blocked by a specific, recurring structural problem, and almost every high-impact gotcha traces back to it. The one thing that would change everything: verification & preview Every launch today requires a full per-contact byte-equal readback, and even that can’t confirm the email is correct. Writes fail silently in five distinct ways — rows vanish from the import response (#22), rows come back skipped with no field writes (#27), name/underscore mismatches drop fields (#18), platform-suppressed addresses skip silently (#25), and any PATCH full-replaces and wipes the other 9 fields (#14/#28/#30). So I readback everything. Then — because there is no API that returns the merge-resolved, HTML-rendered email — an operator still has to eyeball one rendered message in the UI to catch {{Herr_Frau}} non-resolution, empty-body halts (#15), and text-wall rendering (#23). That manual UI eyeball is the single biggest thing standing between “built” and “world-class autonomous.” What closes it: a real render/preview endpoint — fully merge-resolved subject + HTML body, per step, per contact, exactly as it would send. ⭐ Actionable now: the Aug 11 changelog we just reviewed shipped GET /v3/sequences/{sequence_id}/contacts/{contact_id}/preview — and the path is not scoped under /ai-sdr/. That might already be the general preview endpoint I’ve been asking for. This is worth a live test immediately; if it renders regular (non-AI-SDR) sequences, it eliminates the #1 manual bottleneck and I’d rewrite the pre-launch checklist around it. Want me to test it against a throwaway sequence + contact? The full prioritized ask list (each tied to the manual work / risk it removes) Tier 1 — trust the write, see the render 1. Render/preview endpoint (above) — kills the UI eyeball rule and half the readback ritual. 2. Merge-not-replace field writes — a PATCH that touches only the fields sent, or PUT …/contacts/{id}/custom-fields/{fieldId}. Deletes the most destructive class outright (#14/#28/#30) — right now a one-field title edit wipes all custom fields. 3. Honest import semantics — per-row status that distinguishes written vs skipped-no-write vs suppressed, each with a reason; never drop rows from the response (#22/#25/#27). Today skipped/updated are ambiguous and the tally lies. Tier 2 — enrollment truth 4. GET /v3/sequences/{id}/contacts/count + reliably-paginated membership that doesn’t randomly drop members (#17/#29, and the large-page drop in the Atlas note). This retires the v1-enroll-fallback + double-sweep + MCP-tiebreaker dance I do on every push over 100 contacts. (This count endpoint was “coming late July” → now slipped to late August per the changelog — it’s the one operational item I’m genuinely waiting on.) 5. A first-class v3 enroll that overrides “in another sequence” and returns explicit Added/NotProcessed — i.e. promote the MCP add_contact_to_sequence behavior into REST so I stop reaching for the legacy v1 x-api-key addandpushtocampaign (#16/#29). Tier 3 — the structural one 6. Per-enrollment field snapshotting. Custom fields are contact-global and resolved at send time, so a prospect in two sequences can’t hold two different bodies (#20). Reply’s confirmed snapshot-at-enrollment is a feature request, not shipped. Getting it would delete an entire subsystem I maintain — the namespaced-slot assignment machinery (V6_SLOT_ASSIGNMENT_SPEC). Tier 4 — MCP build parity + reporting 7. MCP tools to create/edit sequences, steps, and upload attachments (+ webhooks CRUD). Today building is REST-only (#10); the MCP tools are self-documenting and trap-proof, so moving the build path onto MCP would cut the error surface on the riskiest part of the job. 8. Meeting lifecycle write-back (held/no_show/rescheduled) + a bulk-by-email status setter (#13) — needed for fully automated reporting. 9. Consistent cursor pagination on every list endpoint — email-accounts is skip-only and hid a client’s real senders past page 1 (#21); schedules has no pagination and dumped 392 records → context overflow. One cursor style everywhere. Tier 5 — cleanups 10. Fix (or formally deprecate) emailTemplateId on v3 steps and template PATCH/DELETE (#1/#3b) — dead paths I route around. 11. whoami/team-users returns 403 on this legacy account — workspace/team access would unlock clean multi-client owner→name resolution for reports. Meta-tax worth naming Most of v3 is still Beta — “shapes may change without notice” (#9), which is why I re-verify request shapes after every changelog. A stable versioned contract (or a changelog webhook) would remove standing overhead — but that’s a maturity ask, not a feature. Bottom line: I don’t need new endpoints to function — the skill already encodes reliable workarounds for all 30 traps. What separates functional from world-class is (1) a render-preview endpoint and (2) writes/imports I can trust without a full readback.