API Changelog

Text messages and WhatsApp get real conversations. A text thread now closes after fifteen minutes of quiet and the next message opens a new conversation carrying a summary of the last, so GET /api/v1/apps/{appId}/conversations reads one row per occasion instead of one endless row per customer. The id keeps the customer's thread as its prefix and gains -s2, -s3; group by that prefix or by callerIdPhone. A conversation taken over by a team member does not roll while they are handling it.

A text conversation is visible as it happens. Conversations now carry source: "sms" or "whatsapp" and the customer's callerIdPhone from the first message, and appear in the list the moment they start rather than once they have been summarised. Both dashboards show the channel on the row.

HELP, STOP and START are answered by the platform. HELP and INFO return one fixed line built from the app's name and the number texted. STOP and its variants now record the opt-out on the customer's record as consents.reminders.sms = false, and every outbound text path consults it: the reminder sweep skips that customer and writes skipped:opted-out against the rule. START lifts it. Previously the platform relied on the carrier's own block, which only covers the pair of numbers that saw the STOP — and reminders go out from a different number than the one customers text. An opt-out from texts leaves email and phone reminders, and marketing consent, untouched.

The assistant knows it is on a text message. It is told the channel and the sender's number, so it writes the way a person texts and never asks for a number it already has. On SMS it answers in words rather than cards or pickers; WhatsApp still renders them as native tappable lists.

Longer conversations answer from the right end. Stored conversation history was being read oldest-first and capped, so a long-running thread could answer from months-old context and miss what was just said. Every channel now reads the most recent turns.

See what your reminders did. A phone reminder now appears in the conversation list with source: "reminder-call" and a reminder block (bookingId, ruleKey, attempt, outcome), on GET /api/v1/apps/{appId}/conversations and the single-conversation read. Each booking's commsSent markers keep the conversation id, the call length and any note. GET /api/v1/apps/{appId}/booking-reports gains reminders: counts by channel for the window and, for calls, how many were reached and what came of them.

Hear the reminder call first. POST /api/v1/apps/{appId}/booking/reminder-call/preview reads back the exact spoken lines and persona a reminder would carry, with a sample booking and optionally an unsaved calls block; POST .../reminder-call/test rings a number you give with that same call and records nothing against any booking. Both in Bookings, Messages, under the phone call section, alongside the quiet hours for texts and emails.

Outbound persona for phone reminders. A reminder call no longer borrows the inbound receptionist's instructions; it speaks with the platform's outbound manner (says who it is, asks for the customer by name, one sentence at a time, never the inbound greeting). Each app can now set the outbound voice, its own words for the opening, the language it opens in, how quickly it takes its turn and the recording notice, under booking.comms.calls.persona in PUT /api/v1/apps/{appId}/booking and in Bookings, Messages, Phone call reminders. Nothing changes for inbound calls.

Build a demonstration from a website. POST /api/v1/apps/build-from-website (operators) reads a business's public site and builds a demonstration receptionist from it: a published app, a phone number, a booking page in the business's own branding, web chat and the site as knowledge. The app carries demonstration mode (booking.demo): the receptionist discloses it is a demonstration on every call and chat, gives no clinical advice and no suitability judgement, messages nobody, and the booking page banners and confirms bookings as demonstrations (config.demo).

Demonstration landing page and funnel. Each built demonstration gets a landing page (landingUrl) with the number, the booking page, the web chat and the proof layer. Pages report visits through POST /api/v1/public/demo-visit. GET /api/v1/demos/funnel lists every demonstration with visits, return visits, calls and call time, web chats, booking attempts, furthest stage and last activity; PATCH /api/v1/demos/{appId} records replied and notes.

Demonstration cap and teardown. A demonstration is built with a call-time allowance (creditSeconds, default 30 minutes) allocated from the operator's pool, and a life (demoDays, default 14). A daily sweep ends demonstrations whose time is up: the number answers with an ended message, the receptionist is paused, the booking page shows the ended notice; two weeks later the operator is told it can be deleted. PATCH /api/v1/demos/{appId} takes extendDays and end.

The instantly.ai export. GET /api/v1/demos/export.csv gives one row per live demonstration with the merge fields, a cohort question, a PECR column (limited companies only, unless consent is recorded) and the opt-out line; contact and company details are set at build or with PATCH /api/v1/demos/{appId}.