Skip to main content
A routing form asks an invitee a few questions and then sends that invitee to the right destination — a scheduling page, a team page, an external address, or a message. The Routing Forms API builds a routing form, reads its definition, and reads and deletes the submissions that invitees send through it.

​
Scopes

Every read endpoint accepts either scope. Every write endpoint requires routing_forms:write.

​
Build a routing form

A routing form is built in three calls, because the questions and the routes replace as whole lists:
  1. Create a Routing Form writes the routing form with its name and its page settings. The new routing form holds no question and one fallback route that shows the default thank-you page.
  2. Replace Routing Form Questions writes the questions. The response carries the id of each question.
  3. Replace Routing Form Routes writes the routes. A rule names its question by that id, in the inputId field.
Update a Routing Form changes the settings afterwards. It is a partial update: a field that the body leaves out keeps its stored value.
The two PUT endpoints replace the whole list. A question or a route that the body leaves out is deleted. Read the current list, change it, and send it back complete.

​
The two resources

​
Routing forms

GET /routing-forms returns one entry per routing form. GET /routing-forms/{id} adds two lists to that entry:
  • inputs holds the questions. A question carries its type, its options, and the CRM attribute it maps onto.
  • routes holds the routes. A route carries its destination and the rules that select it. Exactly one route of a routing form is the fallback, which takes every submission that matches no other route.
A condition of a rule names its question with inputId on both surfaces. The read endpoints return that key and the write endpoints accept it.

​
Submissions

The submissions of every routing form sit in one feed. GET /routing-form-submissions returns that feed, and routingFormId narrows it to one routing form. Filter further by creation time with minCreatedAt and maxCreatedAt, and by destination with routeType.

​
Read the answers

Each answer ships twice, and the two values serve different consumers: For a question that maps onto a CRM select attribute, rawAnswer is the canonical {"id","value","color"} JSON that identifies the option. The id in it is the value that your CRM needs. answer holds the label alone.
Never show rawAnswer to a person. For a CRM select answer it is a JSON blob, not a label.
questionsAndAnswers repeats the same answers as a flat map from question text to display value. It matches the map that the routing_form.submitted webhook ships, so one parser reads both surfaces.

​
Identifiers

Every id in this API is a UUID.
A malformed id answers 404, not 422. An id that names a resource outside your workspace answers 404 as well, so the response never tells you that the resource exists.

​
Timestamps

Every timestamp in a response is in ISO 8601 format with a UTC offset, for example 2026-04-10T08:30:00+00:00. The minCreatedAt and maxCreatedAt filters accept the same format.
Last modified on September 9, 2026