create_hosted_form

Create a form FormMaker hosts and embeds

Define a form FormMaker will render and host — for an embed snippet or a share URL — and store it. Returns a formId. `submit` picks where answers go, one of three: `contact` posts to an existing HubSpot form (give its `hubspotFormGuid`); `object` posts to a custom-object form you already made with create_object_form (give its `objectFormId`); `new` has FormMaker provision a fresh HubSpot form from the fields itself, no existing target needed — this is the default when the user just wants a form and hasn't named an existing one. For `contact` and `object`, nothing here writes to HubSpot until someone submits the rendered form. `new` is the exception: it writes immediately — it builds the fields HubSpot actually supports (auto-creating a missing contact property when FormMaker has permission), and reports back, by name, any field it couldn't add, so you can tell the user why and what fixes it (grant the property-creation permission on reconnect, or add the property in HubSpot first). Once a form is created, give the user its share link (formmaker.co.in/f/{formId}) and the embed snippet, and mention it can be removed later with delete_hosted_form — which is also how to undo a `new` form's HubSpot form. Fields, labels, and theme are presentation. Give `template` instead of `fields` to start from a ready-made form, and `brandUrl` to theme it to a website automatically. `steps` and `mode` control the form's shape — how it is split across screens, and whether it asks one question at a time. To change a form's title, colours or button text later without recreating it, use `update_hosted_form`. Before building anything beyond a trivial form, talk to the user like a helpful expert: ask ONE simple question at a time, in plain language, confirm what you heard in a sentence, then build. For a scored assessment, ask: what are you assessing? what are the questions, and what makes an answer strong or weak? what should the result say for a high score vs a low one? Then set `optionScores` per option and `results` buckets. For a calculator, ask in plain language: what do you want to show the visitor — savings, a price, an ROI? Which few numbers should they type in (make those `number` fields)? How do those combine into the result (the formula)? Then add one `computed` field with that `formula` and a `format`. Ask one question at a time and confirm before building. For a quote builder, ask in plain language: what options can someone pick, and what does each one cost? Build each choice as a field whose options carry per-option prices (`optionScores`), then add one `computed` field whose `formula` adds those fields together for the live total. For a product/plan finder, ask in plain language: what are you helping people choose between? Which one or two questions narrow it down? Then use `jumps` to route by answer — send an early clear answer straight to its recommendation (`toStep: "result"`), and route others to more questions. Pair with `results` so each path ends on the right recommendation screen. Never dump a list of technical questions on the user.