Send answers to your own systems

Integrations are configured per eflow, on its Integrations tab. They decide where an answer goes in addition to Acquainto — nothing here affects whether you collect answers, only whether they are pushed onward.

You do not need any of this to start. A link with no integration configured collects perfectly well; the responses wait for you under Feedback until you are ready to wire something up.

There are three, plus a one-off download.

A webhook

An https:// URL of your own. Acquainto sends it a signed POST when a conversation completes (response.completed) and, separately, when someone leaves mid-conversation (response.abandoned).

Delivery history is on the same tab, so a failed delivery is visible rather than silent.

A webhook is also how you connect Zapier, Make or n8n, with nothing to install on either side — step by step in Connect an eflow to Zapier.

Check your endpoint before you have a single response

Send test event, under the URL field, sends one real delivery to the URL you have saved. Signed with your real signing secret, carrying the same body a real response will, logged in Delivery history like any other. You do not need to publish the eflow, and you do not need anyone to answer it.

Use it the moment you paste a URL in. It is the difference between “I have configured a webhook” and “I have seen my endpoint accept one”.

The result appears beside the button within a second or two, and it is your endpoint’s verdict rather than ours: accepted it, the HTTP code it replied with instead, or that we could not reach it at all.

Three things worth knowing:

• It goes to the saved URL. If you have typed a change and not saved it, the button says so rather than testing the old one behind your back.
• Your handler can tell it is a test. The body carries "test": true and the request carries an Acquainto-Test-Event header. Check either one and stop before you create a record — otherwise a test will make a customer who does not exist.
• It is tried once. A real delivery that fails is retried for about a day; a test is not, because you are sitting in front of the answer. Retry in Delivery history sends it again when you want another go.

The answers in it are placeholders, but the field keys and the shape are this eflow’s real ones — so a mapping you build against what arrives is a mapping that works on your first real response.

Nothing is created on your side: no response, no answers, no AI usage. That is the point of it. Answering your own eflow to see a webhook fire works too, but it costs you an AI call and leaves a fake response in your data that you then have to go and delete.

Map on the field key, not the question text

The payload carries the answers twice, and the conversation once:

• answers — a list, each entry carrying the question’s text, the value, and how it was answered.
• values — a flat object of field key → answer, each in its real type.
• answersByKey — the same keys with the answer exactly as the respondent typed it.
• questions — each question’s wording and kind, so you can show an answer to a person without asking us for the wording again.
• transcript — every turn of the conversation, in order.

A multiple-choice answer carries both halves. value is the stored choice; it does not change when you reword the option, so it is the one to map into a dropdown or an enum. label beside it is that wording — map it into anything a person will read. answersByKey carries the value.

Map on values. A list flattens by position in Zapier, n8n, and anything else that flattens JSON — and because eflows branch, position 2 is not the same question on the next response.

values gives you each answer in the type it really is. A rating arrives as the number 9, not the text "9", so “rating is above 7” is a rule you can write. A money amount arrives as 1500.5, with its currency in questions beside it. A date arrives as 2026-10-01 however the respondent wrote it.

answersByKey is the older block and carries the respondent’s own words. It has not changed — if you already map from it, nothing has moved.

A phone number can arrive without a country code. When the respondent did not give one we deliver the digits they typed and mark the answer confidence: "low" rather than invent a country. Check it before you dial or text it.

A field key is fixed when a question is created and does not change when you reword the question. That is what makes it safe to map on.

The Response fields table

The Response fields table on this tab lists every field key this eflow will send, beside the question it belongs to, its type, and whether it is required. Each row has a copy button, and there is a sample payload carrying all of them.

It renders before you have set a webhook URL at all — deciding whether a webhook is worth wiring up is exactly when you want to see what it would carry. And it means you can build the mapping before the first real response, rather than pointing a live eflow at your endpoint and reading what arrives.

Two things the table will tell you, and both are normal rather than errors:

• A key behind a branch is absent from every response that went the other way. Those rows are marked Only asked after: ….
• A skipped optional question arrives with a null value.

Who the response is from

The body opens with two fields that say whose answers these are, so a webhook into a CRM can find the right record without a second lookup:

• subjectRef — the identifier you gave when you created that person’s personalized link, usually their email or your own customer id. This is the field to match on.
• prefill — whatever you already knew about them when you made the link, handed straight back with your own key names.

Both describe the person, not the conversation. If you asked something the prefill already covers and the respondent said otherwise, the answer is the newer fact and the prefill is the older one.

subjectRef is null whenever there is nothing to say: the respondent came through a public link or an embed rather than a personalized one, the link was made without an identifier, or your account’s respondent-label retention window has since cleared it. prefill is simply absent in the same situations — not an empty object — so if (body.prefill) is the check.

A third field, ref, carries whatever tag was pasted onto the plain hosted link as ?aq_ref= — a zero-setup alternative for a mail-merge tag or a campaign id, with no personalized link required. Unlike subjectRef it is never verified: anyone who saw the link could have edited that part of the URL, so treat it as a label, not a lookup key. It sits beside subjectRef rather than replacing it when both are present, and it is null whenever the link carried none.

The language it was answered in

The body also carries language — the language the conversation was actually held in, as a standard language tag (tr for Turkish, pt-BR for Brazilian Portuguese). It is worked out from the respondent’s first typed reply and then fixed for the rest of the conversation, so one eflow running across several markets can be filtered, counted or routed by market without anyone reading the answers first.

It is null when there was nothing to work it out from — a conversation answered entirely by tapping options types nothing. It is never filled in from the language your eflow is set up in: “this respondent wrote Turkish” and “this eflow opens in Turkish” are different facts, and the first is the one worth routing on.

Nothing is translated anywhere. The answers and the conversation are exactly what the respondent wrote.

The conversation comes with it

transcript is the conversation itself: each turn’s role, its content, and the order it happened in. Turns that came out of a specific question also carry that question’s questionKey and questionSlug, so a turn can be lined up with the answer it produced.

It is there to be read and archived, not mapped. Keep your column mapping on values; the shape of a conversation changes from response to response, which is the whole reason the structured fields exist.

Two things are never in it: the instructions we give the assistant, and the assistant’s internal reason for having re-asked something. Those are ours, not a record of your respondent.

A very long conversation is trimmed here and marked transcriptTruncated. GET /v1/responses/{id}/transcript always has all of it.

Once it is delivered, it is theirs

A delivered payload is a copy on your endpoint, or wherever an automation listening on it sends it next. Deleting a response in Acquainto does not un-send it. Manage or delete it at the destination.

What that copy holds is more than the extracted fields: the conversation verbatim, and the respondent’s own identifier under subjectRef — usually an email address — beside anything you prefilled about them. So an erasure request for one person, and the retention setting that clears respondent labels on a timer, both stop at our edge; a payload delivered last month still has their email in it. If your endpoint forwards somewhere you would rather a respondent’s name and words did not go, this is the place to check.

Google Sheets

Connecting creates one new spreadsheet for this eflow and appends a row every time a conversation completes. Acquainto can see only the spreadsheet it created, not the rest of your Drive.

Numbers arrive as numbers. Amounts, counts, ratings and dates land in real number and date cells, so AVERAGE, SUM, sorting and date filters work on them without converting anything first. Because the cell holds a bare number, the currency and the rating range move into the column heading — Monthly budget (USD), Satisfaction (1–10). Phone numbers stay as text, so a leading + or 0 is not eaten.

There is a Language column at the right-hand end, carrying the same tag the webhook does and blank for the same reason. It is at the end rather than beside the other response details on purpose: columns are only ever added to the right, because the rows already in your sheet are written against the positions they have, and moving a column would quietly turn every one of them into an answer to a different question. A spreadsheet connected before this existed picks the column up the next time a response arrives.

Erasure does not reach the spreadsheet either

The same asymmetry as a webhook, and it is worth more words here because of which column. Deleting a response in Acquainto does not remove its row. Neither does an erasure request for one respondent, nor the retention setting that clears respondent labels on a timer. Disconnecting leaves the spreadsheet in your Drive.

The Respondent column holds the label the conversation started with. Where someone arrived through a personalized link you minted for them, that label is whatever you minted it with — usually their email address. So a spreadsheet you connected months ago can still be holding an email address you have since been asked to erase, beside whatever that person typed into the answer columns.

We will not edit your spreadsheet to fix that, and that is deliberate. It is your document. You may have filters, formulas, a pivot table or an automation built over it, and a row that changes or disappears underneath those without you asking is its own kind of harm. An erasure request made to us is not permission to edit your Drive.

So clear it yourself, as part of the same request:

• Search the sheet for the identifier itself, not the Session ID — once the response is erased that id no longer resolves to anything here, and your sheet is the only place it still appears.
• Delete the whole row rather than the one cell. The answer columns can hold personal details the respondent typed themselves.
• Deleting rows shifts everything below them up. If a formula, a chart range or an automation keys on row number, clear the cells instead.

The way to avoid the problem entirely is to not send an identifier as the label: mint personalized links with your own customer id rather than an email, and the Respondent column then carries something only you can resolve to a person.

If the panel says Google Sheets is not set up on this deployment, that is an administrator step on our side rather than anything you can fix in your account.

Email notifications

Email your team when a conversation completes. Up to 10 recipients per eflow.

One switch governs the whole card. Email notification on completion is off until you turn it on, and while it is off nothing below it sends — whatever the recipient list says. The card states which it is in words as well as color, and the list marks itself Paused so an address switched on for itself cannot be mistaken for an address that is being emailed.

Two things about recipients:

• An address is emailed nothing until it is confirmed. Adding one sends a confirmation link; the badge reads Awaiting confirmation until someone clicks it.
• Each recipient can be switched off individually without being removed, and removing the last one turns notifications off.

The count in the card’s badge is the count that will be emailed: an address has to be switched on and confirmed to be in it. A paused address and an unconfirmed one both sit in the list without being counted, so a card reading “3 recipients” over three inboxes that will not receive anything cannot happen.

What the email contains

A choice, and it is a real one:

• A notification with a link — the eflow, who answered, when, and how many questions, then a link to open it here. No answers in the email.
• Every answer, in the email body — the full response, readable without signing in, by anyone the email reaches or is forwarded to.

If the responses contain anything you would not want sitting in a forwarded inbox, pick the link.

A one-off download

CSV export, on the same tab: one download of every response to date, with the same columns the Sheets sync uses and one more. It is a snapshot, not a connection — nothing keeps updating after it lands.

The extra column is Prefill, at the right-hand end. It is only ever filled in for a response that arrived through a personalized link you created through the API with details attached — what you already knew about that person before they answered. Those details are yours, not theirs: the assistant never saw them, so an answer in the same file can disagree with them. The cell is blank for every other response, and a connected spreadsheet does not carry this column.

The file is UTF-8 and opens as-is in Excel, Google Sheets and Numbers, so accented and non-Latin answers read correctly without an import step.