Typeform and CodeWords: what happens after submit

Typeform's strength is that people finish its forms. The one-question-at-a-time format genuinely improves completion, which means more responses arrive, which means the thing that matters is what happens to them next.

In most organizations, what happens next is that responses land in a spreadsheet or an inbox, somebody reads them when they get to it, and the good ones are acted on a day or two later. For a support request that is acceptable. For a sales enquiry it is the difference between a conversation and a missed one.

What we'll cover

• Why the response is not the finish line
• What the Typeform API reaches
• Connecting it to CodeWords
• Seven automations worth building
• Partial responses, which nobody looks at
• Validating before anything trusts it
• Building it so it survives
• Limits worth knowing about
• What to build first
• Frequently asked questions

Why the response is not the finish line

Speed decides outcomes for some form types. An enquiry answered within the hour is a different conversation from one answered tomorrow. Nothing about a spreadsheet makes that happen.

Routing requires reading. Which responses need a person, which need a specialist, and which need nothing at all is a judgement somebody makes by reading each one.

Free text is where the useful information hides, and it is precisely the part that cannot be filtered on in a spreadsheet.

The respondent hears nothing. Beyond Typeform's confirmation, most people who fill in a form receive no indication that anything happened.

Nobody analyses the whole. Individually handled responses hide the pattern that forty people this month asked about the same missing feature.

What the Typeform API reaches

Responses can be listed and read for a form, including every answer, the completion state, timing, and any hidden fields passed in the URL.

Forms can be listed, read, created, and updated, including their questions and logic, which supports anything managing forms programmatically.

Webhooks fire on submission, which is what lets an automation act immediately rather than polling.

Hidden fields carry context into a response — which campaign, which account, which page — and they are the most underused feature here by a wide margin.

Partial responses are available where enabled, covering people who started and did not finish.

Files uploaded through a form can be retrieved, which matters for anything collecting documents.

Connecting it to CodeWords

CodeWords connects to more than 3,000 integrations, and the connection is made once and reused.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which form, how responses should be judged, and where each kind should go.
3. Authorize the connection with a Typeform personal access token, and point the webhook at the automation.
4. Describe the exceptions: a response with a missing required answer, an email that is obviously invalid, a duplicate submission.
5. Test with real submissions on a copy of the form before anything routes to a person.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

Seven automations worth building

Routing by content. Read the response, including the free text, decide what it is about and how urgent, and route accordingly. Conditional logic in the form handles what you anticipated; this handles what somebody actually wrote.

Immediate acknowledgement with substance. Beyond the thank-you screen, a message that says what happens next and when. This costs nothing and noticeably changes how people experience the form.

Record creation with context. Create the CRM record, the support ticket, or the project entry, including the hidden fields that say where the person came from.

Enrichment before a person sees it. Look up the company, check whether they are an existing customer, and attach what you know, so whoever picks it up starts informed.

Duplicate and quality filtering. Test submissions, obvious spam, and the same person submitting three times, handled before they reach anybody.

Response theme reporting. Group the month's free-text answers by topic and report what came up. This is the analysis nobody does and it is frequently the most valuable output of a form.

Partial response follow-up. Covered below, because it is the most overlooked opportunity here.

Partial responses, which nobody looks at

Typeform can capture responses from people who started and did not finish. Most teams never look at them, and they contain two useful things.

People who gave you enough to contact them. Somebody who answered four questions including their email and then stopped is a person you can reach. Whether you should depends entirely on consent and context, which the form should make clear.

The question where people stop. If a disproportionate number of partials end at the same question, that question is the problem. It is too personal, too much work, or badly worded, and nothing else in your analytics will tell you this as directly.

Be careful with the first and confident with the second. Following up on abandoned responses can read as surveillance — the person chose not to finish — so it needs a genuine basis and a light touch, and for some form types it is simply inappropriate. Fixing the question that causes abandonment carries no such problem and usually improves completion more than any follow-up would recover.

Report the drop-off weekly. It is a short report, it changes form design, and form design changes completion more than anything downstream.

Validating before anything trusts it

Form input is user input, and anything downstream will believe whatever you pass it.

Check the obvious. An email that cannot be an email, a phone number that is not one, a date in the past where it should be future. Catch these at intake rather than in the system that receives the record.

Decide what a missing optional answer means. Not applicable, declined, or overlooked all look identical, and downstream systems will treat them the same unless you decide otherwise.

Normalise before writing. Company names, phone formats, and country names arrive in whatever form somebody typed. Normalising once at intake is far cheaper than cleaning it in three systems later.

Flag rather than reject. A response with a problem should reach a person with the problem noted, not disappear. The person who filled it in does not know it failed.

Never trust hidden fields blindly. They come from the URL and can be altered by anyone who looks at it, so treat them as a hint rather than as fact for anything consequential.

Building it so it survives

Make it safe to run twice. Webhooks retry. Use the response identifier as the key so a retried delivery does not create a second record.

Store the raw response. Whatever you extract, keep the original, because the first time somebody questions what a respondent said you will want it.

Respond quickly to the webhook. Acknowledge first and process afterwards, so a slow downstream system does not cause retries.

Report the outcome. A daily line with responses received, routed, and flagged makes silence meaningful.

Handle the form changing. Somebody will add or reorder a question. Reference answers by field identifier rather than by position, or the automation will silently read the wrong one.

Limits worth knowing about

Rate limits apply to the responses API, which matters mainly when backfilling.

Response retention varies by plan, so historical analysis has a horizon.

File uploads are retrieved separately and have their own size limits and access rules.

Question identifiers change if a question is recreated rather than edited, which breaks automations referencing them and is the most common cause of a form automation quietly reading nothing.

Partial responses need to be enabled and are not available on every plan, so the section above may not apply to your setup.

What to build first

Immediate acknowledgement with substance: a message telling the respondent what happens next and roughly when. It takes very little building, it is the part of the experience most forms get wrong, and it forces you to decide what actually does happen next, which is a more useful conversation than it sounds.

Two habits make the difference. Submit the form yourself weekly and read what you receive, since nobody else will tell you it is wrong. And report responses that could not be routed, because those are the ones that silently go nowhere.

Frequently asked questions

Should I use Typeform's own integrations?

For simple destinations — a spreadsheet, a mailing list — yes, they are native and require nothing. Reach outside when routing depends on reading the answers, when enrichment is needed before a person sees it, or when the response has to reach several systems with different shapes.

How do I route on free text?

Classify it, then route on the classification. This is the work conditional logic cannot do, because the form cannot anticipate what somebody will write. Keep the routing rules deterministic once the classification exists, so the behaviour is predictable.

Can I follow up on people who did not finish?

Where partial responses are available and you have a genuine basis, and carefully. Somebody who abandoned a form chose to, and an eager follow-up reads badly. The more reliable value in partials is identifying the question that causes abandonment, which improves completion for everyone.

Why did my automation stop reading an answer?

Most likely the question was recreated rather than edited, which changes its identifier. Reference fields by identifier and monitor for responses where an expected field is missing, since this fails silently and can run for weeks.

Should I trust hidden fields?

Treat them as a hint. They travel in the URL and anybody can change them, so a hidden field claiming an account identifier should be verified against your own records before anything consequential depends on it.

How fast should the acknowledgement be?

Immediately, and it should say something. "We have received this and someone will reply by tomorrow afternoon" is a different experience from a thank-you screen, and it costs one automation.

What is the most useful report to run?

Free-text answers grouped by theme, monthly. Individually handled responses hide the pattern, and the pattern is frequently the most valuable thing the form produces — more valuable than any individual response it collected.

How do I stop spam submissions reaching people?

Filter on obvious signals before routing — disposable email domains, free text that is clearly generated, submissions arriving faster than a person could type. Flag rather than delete, since a false positive on a genuine enquiry is worse than a spam message reaching somebody.

Should every response get a human reply?

Decide by form type rather than universally. An enquiry should; a satisfaction survey should not, and sending one anyway makes the next survey less likely to be completed. What every response should get is an acknowledgement that says what happens next.

How do I keep the form and the automation in step?

Reference answers by field identifier rather than by position or title, and have the automation report when an expected field is missing rather than quietly reading nothing. Somebody will reorder or reword a question eventually, and the failure is otherwise silent.

What is the right acknowledgement to send?

What happens next and roughly when, in one or two sentences. Not a restatement of what they submitted, which they just typed, and not a promise you cannot keep, which is worse than saying nothing.

Can I route to different people by response content?

Yes, and it is the main reason to automate here rather than using a native integration. The routing logic should stay deterministic once the classification exists, so behaviour is predictable and somebody can explain why a response went where it did.

Related reading

• Calendly and CodeWords
• CodeWords integrations and templates