API reference

A chat link is a self-contained assistant at its own URL. It starts empty and only knows what you give it, so a link built for one role never answers from another's material — and it can inherit your main knowledge base on top when you want both.

• The URL is the credential. It carries a 192-bit token, and the page behind it needs no login.
• Revocable and expiring. Revoke a link and the URL 404s immediately, for everyone holding it.
• Isolated by default. Set inherit_main_kb to also answer from your main knowledge base.

Returned by every management endpoint except DELETE.

{
  "id": "e92c2046-c5c7-46e0-883b-13538feb6037",
  "label": "Toronto campaign",
  "tag": "q4",
  "tags": ["q4", "toronto"],
  "token": "bZY3eWQ80eOn-Pn3F6BPjLlq43q-yUbF",
  "url": "https://agent.reapdat.com/acme/bZY3eWQ80eOn-...",

  "agent_name": null,
  "greeting": null,
  "primary_color": null,
  "language": null,
  "channels": ["chat"],
  "inherit_main_kb": false,
  "created_via": "api",

  "status": "active",
  "is_active": true,
  "is_expired": false,
  "revoked_at": null,
  "expires_at": "2026-12-31T23:59:59+00:00",

  "use_count": 0,
  "last_used_at": null,
  "created_at": "2026-09-12T15:41:55.380471+00:00",

  "kb_sources": {},
  "kb_chunks": 0,
  "kb_docs": 0
}

Every field is optional — posting {} creates a working link that inherits the account's persona, colour, language and channels.

{
  "label": "Careers",
  "tags": ["careers", "hiring"],
  "agent_name": "Alex",
  "greeting": "Hi - ask me about the roles we have open.",
  "primary_color": "#7C3AED",
  "language": "en",
  "channels": ["chat", "call"],
  "inherit_main_kb": false,
  "expires_at": "2026-12-31T23:59:59Z"
}

Three parts: link (the link itself, as JSON), knowledge (an array of entries, as JSON) and files (up to five documents). Only link is required.

POST /api/v1/chat-links/bundle
X-API-Key: ua_admin_...
Content-Type: multipart/form-data

link      = {"label":"Lead iOS Developer",
             "tags":["REQ-43674","ios"],
             "channels":["chat"],
             "inherit_main_kb":true}
knowledge = [{"content":"Contract, remote. Denver CO. 8+ years."},
             {"question":"Do you sponsor visas?",
              "answer":"Not for this role."}]
files     = @role-spec.pdf

{
  "link": {
    "id": "b444447b-8fab-4dc9-ad69-9dfa1d20d03b",
    "label": "Lead iOS Developer",
    "tags": ["REQ-43674", "ios"],
    "token": "EDFIqR3asRlCSL0FY0kB7_cLMGxGF0_B",
    "url": "https://agent.reapdat.com/your-slug/EDFIqR3asRlC...",
    "channels": ["chat"],
    "inherit_main_kb": true,
    "status": "active",
    "kb_docs": 0
  },
  "knowledge": {
    "job_id": "105e015e-e8ab-4b7e-8fbb-ce313691692d",
    "status": "running",
    "queued": 3
  }
}

Pass the link's id as link_id and the content is scoped to that link alone. Omit it and the content goes to your main knowledge base instead.

POST /api/v1/knowledge/portal/ingest
X-API-Key: ua_admin_...
Content-Type: application/json

{
  "content": "Interviews are two rounds: a screen then a panel.",
  "link_id": "b444447b-8fab-4dc9-ad69-9dfa1d20d03b"
}

{
  "success": true,
  "doc_id": "4bb31953-...-62aee3da4241",
  "chunks": 1
}

curl -s -X POST "https://api.reapdat.com/api/v1/knowledge/portal/upload" \
  -H "X-API-Key: ua_admin_..." \
  -F file=@benefits.pdf \
  -F "link_id=b444447b-8fab-4dc9-ad69-9dfa1d20d03b"

Images are checked against their magic bytes, so a renamed extension is rejected, and are auto-captioned so the agent can answer about what is in them.

• CSV and XLSX need either question and answer columns, or a content column.
• JSON must be an array of objects, or a single object.
• TXT is split per non-empty line; PDF and DOCX per paragraph.
• A scanned PDF with no extractable text is rejected — there is no OCR.

inherit_main_kb decides what a link can read. It is the one setting that changes what the agent is able to say.

When true, both are searched and merged by relevance, with the link's own material winning an equal score — the specific answer outranks the general one. At most 5 passages reach the agent per turn, before and after merging.

Scoping applies on chat and on voice alike. On chat the page sends the link with every message; on a voice call the link is stamped onto the knowledge tool when the call is created, so the system prompt summary and every mid-call lookup stay scoped.

Either way the link still knows the account-level basics — your agent instructions, tone, and business facts such as hours, services and contact details. Those are not knowledge-base content and are never link-scoped.

{
  "links": [ /* Link, newest first */ ],
  "count": 3,
  "limit": 20          // -1 = unlimited
}

POST /api/v1/chat-links/b444447b-.../revoke
X-API-Key: ua_admin_...

{
  "label": "Lead iOS Developer",
  "status": "revoked",
  "is_active": false,
  "revoked_at": "2026-09-17T02:52:32.122406+00:00"
}

status is derived and is one of active, expired or revoked — expiry beats the active flag. Setting a future expires_at on an expired link revives it, unless it was revoked by hand.

create ──▶ active ─── expires_at passes ──▶ expired ──▶ future/null expires_at ──▶ active
             │                                        (unless revoked by hand)
             └── revoke, or is_active:false ──▶ revoked ──▶ is_active:true ──▶ active

status is computed on every read. When both apply, revoked wins — so a link that expired and was then revoked does not come back by extending the date.

No authentication. The token in the path is the credential.

The QR encodes the url form, so codes printed before the URL style changed still resolve. An unknown, revoked, expired or inactive link returns the same 404 Chat page not found in every case — the response never distinguishes them.

You send a set of questions and a person's name. We give you a URL. They open it in a browser, agree to being recorded, and have a short spoken conversation with an agent that asks your questions. When it ends you get a written record of what was asked and what they answered.

• Two nouns. A *questionnaire* is the reusable list of questions. A *link* is one send to one person. One link, one person — not a form many people fill.
• The URL is the credential. It carries a 192-bit token, and there is no password, no account and no login for the person answering.
• Opening it spends nothing. A mail scanner that pre-fetches the URL does not consume the link; only pressing Start does.
• The session runs in their browser. It needs a microphone and a camera, so it cannot be driven from a server — that part is theirs, not yours.
• The result is pulled. Poll for it, or fetch one link when you know it finished. See Collecting the result.

• 1. Create. POST /questionnaires/bundle with the questions and the person. You get back a URL.
• 2. Send it. By your own email, your ATS, your CRM — we do not send it for you.
• 3. They answer. They open the URL, agree to the notice, and talk to the agent. Typically five to fifteen minutes.
• 4. Collect. Poll GET /questionnaires/links/all, then fetch each one with GET /questionnaires/links/{token}/result.
• 5. Keep or remove. Download the PDF, stream the recording, or delete the media early.

A question with no points is open: it is asked, and whatever they say is recorded. A question with points is expected: the same question, asked the same way, but the write-up afterwards reports which of those points their answer actually covered, with their own words as the evidence.

{
  "questionnaires": [
    {
      "id": "e4b4e816-7d2e-45c2-b6c8-3f0aa0c1fef6",
      "title": "Support engineer - first round",
      "about": "",
      "questions": [
        { "text": "Tell me about your support experience.",
          "kind": "open", "points": [] },
        { "text": "Which Spring Boot version do you run?",
          "kind": "expected", "points": ["Spring Boot 3"] }
      ],
      "question_count": 2,
      "recording_mode": "audio_video",
      "expected_minutes": 8,
      "context_text": "",
      "monitor_activity": true,
      "link_count": 1,
      "created_at": "2026-09-21T15:11:37+00:00"
    }
  ]
}

If your questions live in a document, read them first and send back what you got. POST /questionnaires/parse takes {text} and POST /questionnaires/parse-document takes a multipart/form-data file (PDF, DOCX, TXT, MD, CSV). Both return a proposed questions array plus note, expected and open counts, and store nothing — so your code can check what was understood before anything exists, which is the same confirmation step the browser builder puts in front of a person. A document that cannot be read is a 400 with a detail sentence; when the file extracted but the questions did not parse, that 400 also carries the extracted text, so a bad parse is recoverable by hand instead of a dead end. If the reader itself is down you get a 503 saying so — retry that one rather than reformatting a document that was never the problem.

monitor_activity turns the proctoring on or off. Off is the default, and is the right choice for most uses — an intake call, a pre-visit questionnaire, a vendor check.

• Consent is taken before anything is captured. The person is shown one screen naming what is recorded, that both sides of the conversation are in the file, who sees it and how long it is kept, and ticks one box. What they were shown is stored with a version stamp, so the record can say *which* wording was agreed to.
• The recording carries the agent too, not only them. That is said on the screen, because a person told "you are being recorded" pictures their own voice.
• Media is deleted at 90 days and the written record at 180, stamped on the row when it is written rather than worked out later by a nightly job.

• Revoke is idempotent, and it does not destroy anything: revoking a link that was already answered leaves result exactly as it was. status becomes revoked and stays there.
• Deleting the recording leaves the record. Afterwards recording.available is false, bytes and delete_after are null, url is "", and report_pdf_url still works — the PDF is built from the written record, not from the media. The evidence stills go with the recording, so that PDF no longer carries the pictures; evidence_frames still lists the times.
• Three deletes, three blast radii, and picking by name alone will get it wrong. DELETE .../recording takes the media and keeps the written record. DELETE .../links/{token} takes the whole send, record included. DELETE /questionnaires/{id} retires the QUESTIONNAIRE and keeps every response ever collected from it — the one that sounds the most destructive is the least.
• None of them can be undone. There is no restore and no bin. The files go before the row on the link delete, so a failure leaves everything in place rather than a record that claims the media is gone while it is still on disk.

The knowledge base is what the agent answers from. Everything in it is retrievable by whoever is talking to the agent — a visitor on the widget, a caller on the phone — so treat adding to it as publishing, not as storage.

• Five kinds of source. Documents you upload, pages we crawl, Q&A pairs you write, photo albums, and question sets. They differ in how they arrive and not in what happens next: every one is chunked, embedded and searched the same way.
• Source priority decides ties, not truth. When two sources could answer, the ranked order breaks it. It does not make a wrong page right.
• Deleting is immediate. The chunks go and the agent stops answering from them on the next question. There is no soft-delete tier to sweep later.

Three shapes, one destination. link_id scopes a write to a single chat link's isolated knowledge; omit it and the write lands in the Main KB that the vanity slug and the voice agent read.

curl -X POST https://api.reapdat.com/api/v1/knowledge/portal/ingest \
  -H "X-API-Key: $REAPDAT_ADMIN_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "question": "What are your opening hours?",
    "answer": "Monday to Friday, 9am to 6pm. Closed on public holidays."
  }'

parent_doc_id is the handle for a whole source — a file, a crawled page, one Q&A pair — and the chunks under it are an implementation detail you never address directly.

A named list of questions, written once and reused. They live in the knowledge base because they are the same kind of thing as the rest of it — material a business writes down and reuses — and the Questionnaires API copies one when it creates a session.

These are the endpoints worth polling if you are showing a health widget in your own product. None of them are cheap enough to call per page view.

Three nouns and one pipe. A template is what to say, on one channel. An audience is who to say it to. A broadcast ties them together and sends. Everything else in this reference is a detail of one of those three.

POST /communication/templates              -> template_id
POST /communication/audiences              -> audience_id
POST /communication/audiences/{id}/contacts
POST /communication/broadcasts             -> broadcast_id
POST /communication/broadcasts/{id}/preview   <- required
POST /communication/broadcasts/{id}/send

• One message per person, not one per channel. A broadcast lists channels in order and each contact gets the first one they qualify for.
• A message to one person is a broadcast with one contact. POST /send-one is a shortcut over the same machinery, not a second path — so it passes the same checks.
• Nothing is silently dropped. Every contact a check excludes becomes a durable row with a reason you can read back.
• A send cannot start until its dry run has been read. That is enforced, not advised.

Every endpoint takes either a portal session or an admin API key, and both resolve to the same account. Server-to-server, use the key.

X-API-Key: ua_admin_...
Authorization: Bearer <portal session>

Outbound messaging is on for every account by default. It can be switched off per account, and while it is off every endpoint here answers 403 with "Communication is not enabled for this account yet." — with one exception: GET /communication/readiness always answers, so your own UI can ask whether to show anything at all. Being enabled is not permission to message anyone: consent is still per contact per channel, and a channel with no sender configured still reports itself as not ready.

curl https://api.reapdat.com/api/v1/communication/readiness \
  -H "X-API-Key: ua_admin_..."

{
  "enabled": true,
  "channels": {
    "email":    { "ready": true,  "reason": "", "sender": "Bright Smile Dental" },
    "whatsapp": { "ready": true,  "reason": "", "sender": "+14375240673" },
    "sms":      { "ready": true,  "reason": "", "sender": "+14375240673" },
    "voice":    { "ready": true,  "reason": "", "sender": "+14165550123" }
  },
  "segments": {
    "leads":    "Everyone your AI has captured as a lead",
    "bookings": "Anyone who has booked an appointment",
    "callers":  "Anyone who has called you",
    "chatters": "Anyone who has chatted with your assistant"
  }
}

Read channels[x].ready before you build anything around a channel. A channel that is not ready still accepts templates — you can write them now — but every message on it is blocked at send time with channel_not_ready, and reason is the sentence to show your user.

A template belongs to exactly one channel. Write as many as you like — the limit is 200 per account. Variables are named, in double braces, and any name works: nothing registers a field anywhere.

curl -X POST https://api.reapdat.com/api/v1/communication/templates \
  -H "X-API-Key: ua_admin_..." -H "Content-Type: application/json" \
  -d '{
    "name": "Invoice due",
    "channel": "email",
    "subject": "Invoice {{invoice_no}} for {{business.name}}",
    "body": "Hi {{contact.name}}, {{amount}} is due on {{due_date}}. Pay here: {{login_link}}",
    "category": "utility",
    "language": "en"
  }'

{
  "id": "1f95d26c-…",
  "name": "Invoice due",
  "channel": "email",
  "variables": ["invoice_no","business.name","contact.name","amount","due_date","login_link"],
  "provider_status": null,
  "is_active": true
}

variables is discovered from what you wrote, in first-seen order, and returned so you can show a user which values a template needs. You never declare it.

Optionally, say where each value comes from. variable_sources maps a placeholder to its source. Leave it out and resolution is exactly as above — a contact column, then one of your own fields. Set it and you can pin a value, ask for one from the page a panel is embedded in, or leave a blank for whoever sends the message to fill.

curl -X POST https://api.reapdat.com/api/v1/communication/templates \
  -H "X-API-Key: ua_admin_..." -H "Content-Type: application/json" \
  -d '{
    "name": "Interview moved",
    "channel": "sms",
    "body": "Hi {{name}}, your {{job_title}} interview moved to {{new_time}}. We are at {{office}}.",
    "variable_sources": {
      "name":      { "from": "recipient.name" },
      "job_title": { "from": "page" },
      "new_time":  { "from": "typed" },
      "office":    { "from": "fixed", "value": "Andheri East, Mumbai" }
    }
  }'

{
  "id": "7c41e9a8-…",
  "variables": ["name","job_title","new_time","office"],
  "variable_sources": { "…": "as sent" },
  "context_keys": ["job_title"],
  "typed_keys": ["new_time"]
}

context_keys and typed_keys are derived from the mapping and returned so you can show a user exactly which values to supply and which will be typed. Do not keep your own copy of that list — it changes when the mapping does.

Every rendered value is sanitised: newlines, tabs and control characters collapse to a single space. A URL is unaffected; a pasted multi-line value cannot split an SMS or break a WhatsApp parameter.

PATCH /communication/templates/{id} edits one. DELETE deactivates rather than removes it — a sent message references its template, and the log has to keep being able to say what was sent. A template in use by a running broadcast refuses to be deleted with 409.

POST /communication/templates/{id}/preview renders one against sample values and returns {subject, body, params, missing, sms} — useful for a live preview in your own editor. missing is the same list the send-time check uses.

Meta approves WhatsApp templates before they can send, and it approves them with positional placeholders — {{1}}, {{2}} — not names. A send whose parameter count differs from the approved template is rejected outright.

You never deal with that. Write named variables like any other channel; on submit we translate to positional, send that to Meta, and store the mapping on the template. At send time the parameters are built from the stored map, so the count always matches by construction.

you:   Hi {{contact.name}}, your {{plan}} is due {{renewal_date}}.
Meta:  Hi {{1}}, your {{2}} is due {{3}}.
map:   { "1": "contact.name", "2": "plan", "3": "renewal_date" }
send:  ["Priya", "Gold", "14 Mar"]

• A repeated variable takes one position. Meta counts distinct placeholders; passing a duplicate twice is a count mismatch.
• A body may not begin or end on a variable. Meta rejects that, so we refuse it at save time with a 400 rather than days later with an opaque rejection.
• Editing the wording drops the template back to draft. Meta approved specific text; a changed body has to be approved again.
• A reviewer sees an example, and we build it from your own data. Meta requires a sample value for every placeholder and refuses the submission without one. We render the example from one of your contacts through the same path a real send uses, so what the reviewer judges is what your customer would actually receive. With no contacts uploaded yet the values are padded — it still submits, it just reviews on weaker evidence.
• Approval is pulled, not pushed. Meta has no callback for template review, so provider_status updates when something asks: listing templates, or a queued broadcast reaching its send. A broadcast queued while its template is still in review sends itself once it clears — you do not have to come back and start it.

category is a billing decision as much as a policy one — WhatsApp charges marketing several times the rate of a utility message. Pick the one that honestly describes the send: utility, marketing or authentication.

A template's response carries sms_characters, sms_segments and sms_unicode so you can show the cost before it is written. One non-GSM character — a curly quote pasted from a word processor, an emoji, an accented name — drops the per-segment budget from 160 characters to 70, and a message that looked like one segment becomes three.

dlt_template_id is on the template for India, where every SMS body must be pre-registered on a carrier DLT portal. Unregistered traffic there is dropped silently rather than rejected loudly, which is why the id lives on the template it belongs to rather than in account settings.

• It sends from YOUR number, not ours. Whatever is registered to the account is the From, so the recipient sees a number they recognise and the traffic runs on your carrier registration rather than the platform's.
• We append the opt-out line — “Reply STOP to opt out” — unless your body already says something equivalent. Two opt-out sentences in one message reads as a mistake and wastes a segment, so we check before adding.
• An inbound STOP clears that contact's SMS consent on your account, immediately and for every future send. It is matched on the number that texted and the number it texted, so it clears the right account's contact and nobody else's.

voice places a real phone call from your number, and the assistant that answers your inbound line is the one that speaks. It is not a recorded announcement and not a text-to-speech read-out: the person can interrupt, ask what it costs, and be booked in — the knowledge base and the booking engine are available mid-call, the same as on any other call you take.

Because of that, a voice template's body is a brief, not a script. Write what the call should achieve; the assistant phrases it live. A verbatim script gets read aloud badly and throws away the one advantage a call has over an SMS.

curl -X POST https://api.reapdat.com/api/v1/communication/templates \
  -H "X-API-Key: ua_admin_..." -H "Content-Type: application/json" \
  -d '{
    "name": "6-month recall call",
    "channel": "voice",
    "body": "Remind {{contact.name}} their check-up is due and offer to book a time. If they are not interested, thank them and ring off."
  }'

{
  "id": "…",
  "channel": "voice",
  "variables": ["contact.name"],
  "is_active": true
}

There is no way to make a cold AI call through this API, and that is structural rather than a policy. The country matrix refuses cold AI voice in every market we operate in, and the voice channel is mapped to the opt-in rule, so a contact without consent_voice is blocked before the matrix is even consulted.

• The assistant says it is an AI before anything else. That opening is added to every campaign brief by the platform, not left to your wording — a tenant who forgets it is the account that gets the letter.
• It knows the call is outbound. Without that it opens with the inbound welcome and waits for a request that is never coming.
• Calls are paced, not fanned out. Roughly five a minute. Each one occupies a carrier leg, a voice session and a model for its whole duration, and a burst would collide with the customers trying to ring the same number.
• Readiness needs calling switched on for the account. The number it dials from is your own registered one if you have it, and the Reapdat platform number otherwise — readiness reports which as voice.sender. Briefs can be written before either exists.

An audience is a named list. Four ways to fill one, and they all land on the same normalizer — a contact added by any route is identical to one added by any other.

curl -X POST https://api.reapdat.com/api/v1/communication/audiences/{id}/contacts \
  -H "X-API-Key: ua_admin_..." -H "Content-Type: application/json" \
  -d '{
    "rows": [
      { "name": "Priya Sharma", "email": "priya@example.com", "phone": "+919876543210",
        "plan": "Gold", "renewal_date": "14 Mar", "login_link": "https://pay.example.com/t/9fA2xQ" },
      { "name": "Broken Row", "email": "not-an-email" }
    ],
    "consent": { "channels": ["email"], "source": "ticked the box on our booking form" }
  }'

{
  "created": 1,
  "updated": 0,
  "rejected": 1,
  "rejected_rows": [
    { "row": 2, "reason": "'not-an-email' is not a valid email address",
      "data": { "name": "Broken Row", "email": "not-an-email" } }
  ],
  "total_in_audience": 1
}

• Any key that is not a known field becomes one of your own. plan, renewal_date and login_link above are now {{plan}}, {{renewal_date}} and {{login_link}} in a template. No schema change, no registration.
• Known fields are name, email, phone, country, timezone, external_id and the three consent_* flags. Everything else is yours.
• A bad row is reported, never repaired. You get the row number, the reason and an echo of the data. A near-miss is a miss — we will not guess at a malformed address.
• Re-importing is idempotent. Contacts are keyed on email, falling back to phone. The same file twice updates; it does not duplicate.
• A duplicate inside one upload is collapsed, because the same customer appearing twice in an export is ordinary rather than an error.

POST /audiences/parse reads an uploaded CSV and stores nothing — it returns the headers, a suggested mapping, the variable name each unmapped column would become, and the rows. Show that to a user, let them confirm, then post it to /import with the mapping they chose. Guessing the mapping silently is how an import tool earns a support queue: “Contact” means a phone number at one business and a person at the next.

curl -X POST https://api.reapdat.com/api/v1/communication/audiences/parse-text \
  -H "X-API-Key: ua_admin_..." -H "Content-Type: application/json" \
  -d '{"text": "Priya Sharma, priya@example.com, +91 98765 43210\nRaj K <raj@example.com>\njoined 2026-09-25"}'

{
  "contacts": [
    { "name": "Priya Sharma", "email": "priya@example.com", "phone": "+919876543210" },
    { "name": "Raj K",        "email": "raj@example.com",   "phone": null }
  ],
  "skipped": [
    { "line": 3, "text": "joined 2026-09-25",
      "reason": "no email address or phone number on this line" }
  ],
  "count": 2
}

The paste parser handles one contact per line, the Name <address> form a mail client copies, and a blob of addresses separated by commas. It is regex and validation, not a language model: extracting exact strings is where a model is least reliable, and one changed character sends a stranger somebody else's reminder. Date-shaped runs are excluded before phone detection, or a joined-on date becomes a customer's number.

GET /audiences/{id}/contacts lists them with q, limit and offset. PATCH .../contacts/{contact_id} edits one — every value is re-validated and a near-miss is a 400, never a silent store. Changing an address changes the identity, so the dedupe key is recomputed and a collision with another contact in the same list is a 409.

Consent is recorded per contact, per channel, and checked on every send. It is the first of the checks and there is no override.

{
  "consent_email": true,
  "consent_sms": false,
  "consent_whatsapp": false,
  "consent_voice": false,
  "consent_source": "ticked the box on our booking form",
  "consent_at": "2026-09-25T07:03:08Z"
}

• An import can only GRANT. The consent block on an import never turns a permission off. A revocation has to come from the person, not from a spreadsheet.
• **A row's own consent_* column wins** where present; the import-wide declaration fills the rest.
• `consent_source` is evidence, not decoration. It is what you show when somebody asks why they were messaged, so write what actually happened.
• A segment pull grants nothing by default. Someone having called you is not permission to market to them.

curl -X POST https://api.reapdat.com/api/v1/communication/broadcasts \
  -H "X-API-Key: ua_admin_..." -H "Content-Type: application/json" \
  -d '{
    "name": "February recall",
    "audience_id": "8a4b5821-…",
    "channel_order": ["whatsapp", "email"],
    "template_ids": { "whatsapp": "…", "email": "…" },
    "allow_replies": true
  }'

{
  "id": "62ab9a48-…",
  "status": "draft",
  "channel_order": ["whatsapp","email"],
  "allow_replies": true,
  "send_window_start": null,
  "send_window_end": null,
  "previewed_at": null
}

channel_order is tried per contact and the first channel they qualify for wins — one message per person, never one per channel. Every channel you list needs a template of that channel, or the create is a 400.

{
  "counts":  { "total": 1240, "sending": 690, "held": 188, "blocked": 362 },
  "by_channel": { "whatsapp": 500, "email": 190 },
  "by_reason": {
    "no_consent":       { "count": 312, "label": "They have not agreed to be contacted on this channel" },
    "unsubscribed":     { "count": 44,  "label": "They opted out" },
    "missing_variable": { "count": 6,   "label": "The template needs a value this contact does not have" }
  },
  "samples": [ { "name": "Priya Sharma", "channel": "email",
                 "subject": "…", "body": "Hi Priya Sharma, your Gold plan…" } ],
  "readiness": { "email": { "ready": true, "reason": "", "sender": "…" } }
}

POST /broadcasts/{id}/send returns immediately with the summary; delivery runs behind it and is resumable, so a restart mid-send loses nothing. Poll GET /broadcasts/{id} to watch the counters. POST /broadcasts/{id}/cancel stops anything not yet handed to a provider — what has already gone is out of our hands.

There is no send window by default: a broadcast goes out as soon as it is built. Pass send_window_start and send_window_end (local hours, 0–24) if you want quiet hours — they are applied in each recipient's own timezone, with daylight saving handled, and affected messages are reported as held rather than blocked.

curl -X POST https://api.reapdat.com/api/v1/communication/send-one \
  -H "X-API-Key: ua_admin_..." -H "Content-Type: application/json" \
  -d '{
    "template_id": "1f95d26c-…",
    "name": "Priya Sharma",
    "email": "priya@example.com",
    "attributes": { "invoice_no": "INV-2291", "login_link": "https://pay.example.com/t/9fA2xQ" },
    "send_now": true
  }'

{
  "broadcast_id": "…",
  "status": "completed",
  "message": { "state": "sent", "to_address": "priya@example.com",
               "rendered_subject": "Invoice INV-2291 for Bright Smile Dental" }
}

• `attributes` is where your own fields go — exactly the same names a template uses, no CSV required.
• Consent is granted automatically for that template's channel, recorded as “direct send by the business”. You named this person deliberately; override the wording with consent_source.
• No quiet hours. An individual send is a deliberate act at a moment you chose, so it ignores any window and goes immediately.
• `send_now: false` builds it and returns the preview without sending — the way to show a confirmation screen.
• It is still a broadcast underneath, with an audience of one. Same checks, same log row, same delivery receipts, same reply matching.

Every message is a durable row, including the ones a check excluded. “We sent 690 of 1,240” is only actionable when the other 550 are enumerable.

queued -> sending -> sent -> delivered -> read -> replied
   |          |                |
   |          +-> failed       +-> failed   (a provider accepted, then could not deliver)
   +-> blocked      (a check refused it; it never left)
   +-> cancelled    (the broadcast was stopped)

Sent is not delivered. Sending means a provider accepted the message. A dead number, a landline that cannot take SMS, a handset that is off — all accept, then fail. The real outcome arrives later on the provider's own webhook and is matched back by the id we stored at send time.

Replies are matched exactly, not guessed. We mint the Message-ID when the mail goes out and store it; the customer's reply carries it in In-Reply-To, so the reply names the row rather than resembling it. Sender address is the fallback for channels with no such header. Both are scoped to your account.

{
  "state": "replied",
  "to_address": "priya@example.com",
  "replied_at": "2026-09-25T07:16:41Z",
  "reply_snippet": "Yes please, can we do Saturday morning?",
  "reply_conversation_id": "…"
}

reply_snippet is the first reply's words, whitespace collapsed and capped at 400 characters — the full text lives on the conversation. The first reply wins, not the latest: a thread that runs on is still one answer to one send.

GET /communication/messages is the account-wide log, filterable by state, channel and q (name, address or number). GET /broadcasts/{id}/messages is one send's rows. GET /communication/overview?days=30 gives headline counts plus a breakdown of what was blocked and why.

Every error carries detail as a sentence written for a person, not a code. It is safe to show your users directly — "'not-an-email' is not a valid email address." rather than ERR_VALIDATION_402.