Put a business’s AI assistant on its website: and its work in your systems.

The first call to make. Confirms the key belongs to a business and says which features are on. Cheap enough to call when your server starts.

Everything your site needs so it does not hard-code the business: the assistant's name, what can be booked, and fields, the business's Details to collect, which its team edits in Corva. Build your own forms from fields and send answers back as details (keyed by key); the assistant asks for the same ones in chat and on calls. Read it at start-up or cache it for a few minutes: when the business adds a field, your site picks it up without a deploy.

One message in, the assistant's reply out. It answers only from the business's knowledge (kept in Corva), stays within the limits the business set, collects the business's details as the conversation goes, and hands over to a person when it should. Keep one sessionId per chat.

When it has what a booking or a callback needs, it does not make it, it returns a proposal. Show that as a card with Confirm and Edit and send the customer's answer to POST /api/v1/chat/confirm. A new message replaces an unanswered card.

details is everything collected so far, keyed by the business's field keys. heldBy is set once a person on the team has taken the chat over: reply is then null, and their replies come from GET /api/v1/chat.

With stream: true the answer is text/event-stream: delta events ({ text }) while the reply is written, a proposal event when a card should show, then done with the same body as the JSON answer, or error.

Bookings. For a business that has set up things to book (Bookings in Corva), the assistant checks real open times and may send a slots event, { bookingTypeId, type, date, day, times: [{ time, label }] }, which you can show as buttons that send, say, "11:00 am on Wednesday, 7 Oct". Its card then has kind: "appointment" with details: { type, date, time, when, name, email?, phone?, notes? }. Confirming books the slot; if it filled in the meantime the confirm returns 409 with the times still open. Ignore events you do not recognise.

Call from your server when the visitor taps your Share location button (the browser's location, or a pin on your map) after the chat has started. Corva keeps the point on the customer, or holds it on the chat until they give a name or number. Send the returned message as the visitor's next chat message so the assistant knows and carries on, the same as a location shared on WhatsApp. consent must be true: show a line saying why you ask. With saveAs (Home, Work) and an address, it is also saved as one of the customer's addresses.

Confirm makes what the card shows: the customer's record, a lead with an owner on the team, a follow-up on that person's list, a confirmation email to the customer and a note to the owner. reply is the line to show in the chat and receipt is for the card. Edit tells the assistant they want to change something, show the reply and let them type. Confirming the same card twice returns the first result with duplicate: true.

Anyone on the business's team can take a chat over from the assistant in Corva. Poll this, every eight seconds or so while a chat is open, every three once heldBy is set, and show messages whose from is not "assistant" under that person's name. heldBy goes back to null when they hand the chat back; ended means start a new sessionId.

A website chat has no hang-up, so tell Corva when it is over: the chat window was closed, the page was reloaded, or the customer started a new chat. The conversation is closed at once, resolved if the customer said anything, abandoned if not, and summarised, and conversation.ended goes to your webhooks. Use navigator.sendBeacon to your own server route on pagehide, which then calls this with the key.

If you never call it, nothing breaks: a chat is also ended when the same visitorId starts a new sessionId, or after 30 quiet minutes. Ending a chat that is already over, or a sessionId Corva has not seen, does nothing (ended: false). After it, that sessionId answers 409: start a new one.

Only if your site runs its own chat assistant instead of Corva's. Send the whole transcript after each reply; Corva keeps one conversation per sessionId, replacing it each time, so the team can read every chat live and see where a request came from.

For your own forms, a booking form, a "call me back" button, a contact page. Corva finds or creates the customer by phone, opens (or updates) their lead with an owner on the team, puts a follow-up on that person's list, emails the customer a confirmation and tells the owner. kind: "booking" is whatever the business books (see booking.noun in /config). Every request makes the lead New; a booking with an email gets a confirmation email with a link where the customer confirms it, corrects it and shares their location, after which the lead's customerConfirmedAt is set and lead.updated is sent.

Send the business's own fields as details, keyed by the keys from /config, unknown keys are ignored, choices are matched to the business's options. Safe to retry: the same reference again returns the first result with duplicate: true.

The business's leads, newest-changed first, whichever way they arrived: chat, a call, your forms, or added by hand. Each carries details (the business's own Details to collect, by field key) and request (the latest booking, callback or enquiry as fields: date, time slot, services, address, reference).

Filter on any collected detail with details.<key>=<value>, keys from /config, matched case-insensitively; details.<key>= with no value means "has an answer". Because details are stored by key, a field the business adds tomorrow is filterable tomorrow with no change here.

Page with cursor: pass back nextCursor until it is null. For a sync, poll updatedSince with the time of your last run.

A lead with its customer and its follow-ups, who owes the customer what, by when, and whether it was done.

Keep Corva in step with your own system: when work starts, move the lead to proposal (Processing); when it is done, to won (Converted); add what your team learnt. Send only what changes. Returns the lead as GET does, and tells webhooks (lead.updated) like a change made in the console.

The board is the same five stages for every business. Corva moves a lead itself in three places: a customer telling the assistant who they are makes it New, a confirmed booking makes it Contacted, and a payment reported paid makes it Converted. Lost is only ever a person's (or your system's) decision.

What happens after a booking happens in your system: collected, in progress, out for delivery. Send each order's current state here whenever it changes, under the reference the customer was given, and the assistant can answer "where is my order?" in chat and on calls. The same kind and reference replace what was there. status is read to the customer as it is, write it as a sentence. Name the customer by customer.id, leadId or customer.phone.

What Corva currently holds under a reference, what the assistant would tell a customer who asked.

Tell a customer their order has moved (pickup booked, work started, ready, payment due) on WhatsApp and by email, from the business's own number and sender. You write the message; Corva delivers it. WhatsApp only lets a business write freely within 24 hours of the customer's last message, so outside that window the message goes by email only (the response says which channels went). The same key sends once, however often you post it. Name the customer by customer.id, leadId, customer.phone or customer.email.

Totals for the last days days (1–90, default 7): customers who reached out and how many were new, conversations and who answered them (the assistant or the team) by channel and by day, leads opened, won and lost, follow-ups overdue and due today, handoffs waiting, and each person's calls, chats, follow-ups and wins. For an owner's dashboard on the business's own site; counts only, no transcripts or customer names. Every figure matches Corva's Overview screen, linked in links.

Everyone with access to the business: name, email, phone, the role they hold in Corva and their status. customRole is the name of their custom role in Corva, if any, and corvaAccess is false when that role does not use Corva at all (a driver, a cleaner). When the business uses Orbo for orders and deliveries, delivery says what the person is there, driver, staff, store_manager or regional_manager, and places, the codes of their stores (region codes for a regional manager); via says whether it was set on the person or comes from their Corva role. It is null for people with no role in Orbo. Orbo reads this so a business adds a person once, in Corva. People are added and given a delivery role on Corva's Team screen.

The business's price list in the same shape as the downloadable template: category, name, price (rupees, null when quoted), unit, description, available, sku, gstPercent, hsn, priceIncludesGst. Needs the read scope. Orbo reads this to stay in step.

Send the list in the template's shape. Items are matched by category and name, so sending again updates prices instead of doubling the list; nothing is ever removed. At most 2,000 at a time. Needs the write scope. Orbo sends its list here.

Everyone the business has a record for, newest first. Look one up by phone or email to recognise a returning customer in your own app, these match the number and email on file. Corva keeps one customer across every channel (chat, calls, WhatsApp, email, your records): a number or email someone only typed in a chat is kept on their record as stated but never becomes the one on file, and two customers are never merged on a claim alone.

Verification codes go only to an email the business has confirmed for the customer, so a customer with only a phone number cannot be sent one. This emails them a single-use link; pressing its button confirms that address for them.

Call it only for a person your own system has already identified (someone at your counter, a user signed in to your app). The link proves the mailbox, not who is asking: Corva trusts you for that, as it does for phoneVerified. Never call it for an anonymous visitor who typed a phone number, or anyone could confirm their own email on someone else's record. The answer is the same whether or not anyone matched.

Corva is not a login provider and does not need to be: keep whichever login you already use (your own, Firebase, Auth0, Clerk, Cognito, social sign-in) and, from your server, tell Corva when a person signs up, signs in or changes their details in your website or mobile app. Corva ties your user to the one customer it already holds (their calls, chats, enquiries, orders) or makes one, and answers with what it knows, so your app can say "welcome back" and everything they do next lands on the same record.

How the customer is found. An account already linked is the customer. Otherwise a phone or email you mark phoneVerified / emailVerified (you sent the OTP or the link and they proved it) finds the customer it belongs to and joins their whole history. A number or email you do not mark verified never joins an existing customer, because typing a number is not proof: a new record is made and a match is left for the team (needsReview). Send visitorId (your first-party visitor id) and sessionIds (chats they had before signing in) to attach those anonymous conversations to them. convertLeads: true on event: "signed_up" marks their open leads Converted.

Safe to call on every sign-in: it is idempotent per (app, userId). Needs a key with the website or write scope; never call it from a browser.

The backfill for a business that adds Corva after it has users: up to 100 accounts a call, each linked to the customer Corva already holds by the same rules as a sign-in (a number or email you mark verified joins the history; anything else is made a new customer with a match left for the team). No sign-in is counted and no webhook is sent. signedUpAt keeps their real sign-up date. Safe to run again.

The unified view of a user you registered: their customer, every sign-in linked to it (app and website), what Corva knows (conversations, leads, orders), their open leads and their latest order records. For your own screens; call it from your server.

Say a user closed or deleted their account with you. The sign-in stops identifying anyone in chats; the customer and their history stay (a person who is still a customer of the business). To erase a person's data, use the business's data-request process.

Home, Work and any others the customer saved, the default first. The default is also what the customer's location, PIN code and exact point show, and what a booking is sent with.

Saves an address under a label; the same label again replaces it. The customer's first address becomes their default; send makeDefault: true to switch. Up to 10 per customer. The response says whether the PIN code is one the business serves.

The customer's record, PIN code and store follow it.

If it was the default, the oldest remaining address takes its place.

A customer with everything collected about them (details: the newest answer to each of the business's fields, across all their leads), their leads and their conversations.

For a connected system's staff screen. { claim } (a phone, an email or an order reference) sends a 6-digit code to the contact the business already has for that customer, never to one typed now; the answer is the same whether or not anyone matched. { claim, code } checks what the customer read out: a right code returns the customer, their details, leads and conversations (the shape of GET /customers/{id}); a wrong one returns verified: false. Ten minutes, five tries, six codes per contact a day.

Conversations, newest first, each with the details it collected. The owner's own test conversations are left out unless you ask for them.

from is "customer", "assistant", "system" (an event: a takeover, the call ending) or the name of the person on the team who spoke.

Your system collects the money (your own payment account, Corva never holds the keys). Send each payment's state here whenever it changes: when the link is made, when it is paid, when it expires. The same reference replaces what was there, and a status never moves backwards, so a late expired cannot undo a paid. When it becomes paid, the conversation it was asked in says so, on WhatsApp the customer is thanked, and the lead it was for (that conversation's, else the customer's open one) moves to Converted. Echo requestId and conversationId when Corva asked for the link (see Payments below).

By your reference, or every payment of one customer, newest first.

Each address Corva sends events to, with the events it gets and how its last delivery went. Secrets are never listed: one is shown once, when the webhook is registered.

Register an address for events without opening the console, so a system you connect can set up its own. The answer carries the signing secret, once, keep it to verify Corva-Signature on each delivery (see Webhooks above). Registering an address the business already has keeps one webhook: it gets a new secret and the events you send. Five webhooks at most; the address must be public and https.

Stop sending events to an address. Anything of yours that depended on them stops hearing about changes.

Tell Corva a visitor is on the site. With consent: "necessary" only the visitor id is kept. With "all" (they accepted analytics cookies), the page, referrer and utm_ campaign are kept too, and show on the customer's record once they identify themselves, so the team sees that this lead came from an Instagram ad. Always send the consent your banner actually recorded.

Your server asks for a token (the API key must never reach the browser) and hands token and bridgeUrl to the page, which opens a WebSocket to the bridge and speaks to the assistant. Tokens last five minutes and start one call. The protocol is under “Voice calls in the browser”.

Each stage has a phase, which is what Orbo acts on: a pickup stage opens a pickup stop, a delivery stage opens a delivery stop.

With an order and no amount, asks for what the order still owes. An open link for the same ask is reused unless reuse is false.

Orders and their value, where open orders are, deliveries, money in and owed, stock running low, new and returning customers. Sections appear for the services that are on. For an owner's dashboard, not for doing the work.