Design → AI agent → MCP customization

Design your form or landing page in a tool like Canva, then use an AI agent (e.g. Claude) connected to the JomForm MCP to apply that design and further customize it with CSS and JS. This is the fastest way to get a fully branded checkout without touching code.

The flow

The restaurant menu (QR ordering)

Turn a form into a clean restaurant menu. The menu is a per-form setting, so you configure it on the form itself (Form Settings → Restaurant menu) and it is served at that form's own URL. The workspace home page always stays your normal landing page / form listing, so one workspace can run several menus — two outlets, lunch vs dinner, two brands — simply by using a menu form for each. They are fully independent.

The menu lists only the products the form references through its own product blocks, so unrelated account products can never appear. Pick those into named categories with a searchable product picker and a live preview, and highlight a best-seller. Customers scan a QR stand at the table to order and pay online, and the order reaches you with the table number. Configure it over MCP via set_menu_page /get_menu_page (both take a form_id), or generate the QR stand with generate_qr.

Need more per order — a delivery address, phone number, spice level, notes or pickup time? Attach an optional order form to the menu: the form's own fields render in the checkout step with their labels and required flags, are validated on the server, and are stored on the sale. There is no second field editor — you create and edit those fields in the normal form builder, and the menu settings link straight to it. With no form attached the checkout collects name + email only and still works.

The menu checkout always collects the buyer's name and email (CHIP requires both — they can never be removed), and the server charges each product's live price. The menu is server-rendered and mobile-first: the header shows the table number, cafe name and location with an info panel; a category filter and search let a diner narrow the menu; best-sellers render as two-column square-image cards, and each category as list rows (text left, thumbnail right) with a separator between rows. Items without a photo render cleanly with no empty image slot. All labels follow the workspace default language.

A diner never has to order a single item: the menu carries a basket — see the menu basket for the full behaviour.

Product images on forms

Choose how each product photo appears on your form: size (small 52px, medium 96px, large 160px or hidden) and layout (thumbnail-left, the default, or image-top — a menu-card look with a full-width photo above the name, ideal for a restaurant menu). The renderer serves the matching optimised media variant for the chosen size. Set it in Form Settings → General (with a live preview) or over MCP via set_form_theme (product_image_size / product_image_layout).

Building an order form

Build beautiful order forms with a drag-and-drop builder. Add fields (name, email, phone, textarea, number, select, radio, checkbox, date, time, website, address, consent, hidden, list, repeater, image-choice, captcha), attach products, and publish to your own workspace URL or a custom domain. Forms can be payment forms or response-only — the mode decides what the form collects and what its entries are called, and it is set in the builder.

An agent can build the same form: upsert_form creates or updates it, register_form_fields sets its input fields under a strict contract, and publish_form takes it live.

Publishing a form

Publishing puts your form on the internet at its own URL — the link a buyer opens, or the address you embed. Press Publish in the builder and JomForm confirms it immediately: a panel names the form as live, shows the public URL, and gives you an Open form and a Copy link action, so a first publish never ends in silence. If the URL cannot be resolved yet (for example a workspace whose subdomain is not set up), the panel says so plainly rather than showing a link that goes nowhere.

Two rules decide whether a form may go live. A response-mode form always may — collecting answers is its whole job, and having no products is normal for it. A payment form needs something to sell: publishing one with no products is refused once with a clear message, because such a form can never take money, and you can confirm and publish it anyway if you only meant to collect details. Products can come from a product block, the form's product snapshot, a priced option or shipping choice, or an enabled restaurant menu; adding one any time removes the question.

The same rule covers every way a form goes live — the Publish button, the status control in Form Settings, publishing several forms at once from the Forms list, and AI agents over MCP (publish_form and bulk_forms, both of which accept acknowledge), so an agent is told the same thing you are. A form that is already live is never asked about again.

Custom domains

Put your forms on your own domain (e.g. shop.yourname.com). Add the domain, point a CNAME to custom.jomform.com, and verify. With Cloudflare linked, JomForm can auto-create the CNAME for you. Auto-TLS (Let's Encrypt) uses your account email as the ACME contact by default — you can change it per domain in Settings → Domains.

Form URLs and slugs (rename a form)

Every form is served at the slug you gave it — your-workspace.jomform.com/your-form-slug (or the same path on a verified custom domain). The slug is editable: change it in Form Settings → General and the form moves to the new URL immediately. A slug is 1–40 characters of a-z, 0-9 and dashes (uppercase and spaces are normalised), and it must be free within your workspace — a rename onto a slug another of your forms already serves is refused with an error rather than silently overwriting either form's URL.

Renaming never orphans the URL you already handed out: the old slug keeps working through a temporary redirect (HTTP 301) to the new one, so a printed QR stand, an embedded iframe, a menu's attached order form, and a link already shared in a campaign all keep resolving. The redirect is temporary, not a permanent alias: if another form in the workspace later claims the freed slug, that LIVE form wins and the old URL serves it — a rename's history can never shadow a real form's URL. Slugs cannot be renamed on templates (a template has no public URL) and AI agents do the same thing with the slug parameter on upsert_form, which returns the slug the form now owns.

The menu basket (multi-item ordering)

A restaurant menu is not a one-item form: the menu page carries a full basket so a diner can order a whole table's food in one payment. Here is what the diner experiences and what reaches you. (Nothing to configure — the basket is part of every menu form.)

MCP tools used

Affiliate marketing (referral links & commission)

An affiliate is a promoter you pay for sales they bring. You give each affiliate a short code, and their link is your storefront URL with ?aff=CODE appended — for example https://your-workspace.jomform.com/?aff=ALI. When a buyer arrives through that link and completes an order, the code is stored on the sale, so the sale is attributed to that affiliate and you can see what they earned. Attribution works on menu orders too (the code is carried to the basket checkout).

Create an affiliate link

In the dashboard, open Settings → Affiliates and add a code, an optional name and a commission percentage. The new affiliate appears in the list with its code, its commission and its ready-to-share referral URL. Over MCP, call create_affiliate with the workspace_id, a code, an optional name / email, and commission_pct (10 = 10%); it returns the affiliate, including the referral_url. A code must be unique within the workspace, and creating or changing an affiliate needs the manage or admin role.

Set the commission

Commission is a percentage stored per affiliate. Change it with set_affiliate_commission (takes affiliate_id and the new commission_pct). The rate used is the one stored on the affiliate, so a change applies to sales attributed from then on; it is not written back onto sales that already happened.

How a sale is attributed

The affiliate shares their referral URL. When a buyer opens it, the form (or menu) page reads ?aff=CODE and carries it into the order it submits, where it is stored on the sale as the affiliate code. No cookie, no redirect chain: the code on the URL the buyer used is what attributes the sale. A buyer with no ?aff= simply produces an unattributed sale.

Read an affiliate's sales

Use list_affiliates to get the affiliate ids, then get_affiliate_sales with the affiliate_id (read-only). Each row gives the sale reference, status, total, currency and date. Attribution is recorded on every sale that came in with the code; the commission percentage is the affiliate's current rate (the figures are returned, not a pre-computed payout ledger).

REST endpoints

The same surface is available over the REST API, authenticated as the workspace:

Templates (save a form & reuse it)

A template is a saved form you can start new forms from. It is private to your workspace: it never appears in another merchant's gallery and it has no draft/published state to manage. Build one either way:

• Save form as template in the builder, or Save form as template on the Templates page (pick the form) — its fields and design are copied into a template.
• New template on the Templates page — an empty template, ready to fill in.

You do not have to start from a blank form either: the built-in gallery already covers the common shapes — order forms, booking, donation, contact, survey and more — and cloning one copies it into your workspace as a new draft.

Edit a template's fields and design

The Templates page lists your templates with Edit, Use template, Rename and Delete. Edit opens the template in the same builder you use for forms, so you change its fields, blocks and design exactly as you would on a form, then Save. The builder recognises that it is editing a template: there is no slug, no Publish and no Form Settings — a template is not published and has no public URL, so those controls are not shown.

Editing a template does not change forms already created from it. Cloning a template copies its fields and design at that moment, so a form and its template are independent afterwards: fix a typo in a template and the forms you already made keep the old text until you edit them too. Over MCP the same edit is update_template (with template_id from list_own_templates); the REST equivalent is PUT /v1/rest/templates/{id} with title / config / theme (an omitted field is left unchanged).

A template never lands in another merchant's gallery by accident

Your templates and the public gallery are two separate lists, and the builder's template mode keeps them that way: saving a template writes only its fields and design, never a publish. Publishing a template into the shared gallery is a deliberate, separate act that requires a category and a short description line, so a template can never appear in someone else's New-form picker just because you edited it.

That is because every gallery card is rendered from two fields of the template's own config: the category is config.category, and the description is the value of its first Text block — which is why a gallery card always reads as more than a title. A template you write yourself gets the same treatment: set a category and put a short intro line in a Text block, or its card has nothing to show.

Publishing is therefore checked: a template missing either field is refused with a clear message rather than appearing in the gallery as a bare title. Publishing several forms at once behaves differently on purpose — a bulk publish skips such a template while still publishing the other forms you selected, so one unfinished template cannot block a whole batch. The skipped ids are reported back, so the skip is never silent.

Language: dashboard vs. your forms

JomForm has two separate language settings, and they are deliberately not the same one. The supported languages are English, Bahasa Melayu, 中文, தமிழ் and العربية (Arabic also switches the dashboard to right-to-left).

• Dashboard language — the language you see when signed in. It is a per-user setting: change it on Profile (Dashboard language), reached by clicking your account block — your name and email at the bottom of the sidebar, or at the bottom of the menu on a phone — and it follows you into any browser you sign in from, on any machine. It never changes what a buyer sees. Until you pick one, the dashboard uses the language last used in that browser, and English if there is none.
• Form language — the language your customers see on a public form, the menu, the thank-you page and the password gate. It is set per form or per workspace, never per browser and never from your dashboard choice.

Choosing your customers' language

Resolution is form → workspace → English: a per-form language wins when set; otherwise the form uses its workspace's Default form language (Settings → Storefront); otherwise English. Set the workspace default once and every form you publish inherits it, so a Malay storefront does not need the language set on each form. Over MCP the workspace default is set_workspace_settings with default_lang; the per-form language is config.lang on upsert_form. An unsupported code is rejected rather than stored, so a form can never be left on a language with no strings.

The translation covers the buyer-facing chrome — field labels, the total, the submit button, error messages, the menu, and the footer links (Privacy / Terms / Refund) — while your own field labels, product names, prices and descriptions are shown exactly as you typed them. JomForm does not machine-translate your content.

Which language your emails use

Every email JomForm sends follows the same two-axis rule — the language of the recipient, not of whoever triggered it:

• Emails to you and your team (verify your address, sign-in link, password reset, 2FA codes, connecting a social login, a workspace invitation, a feedback reply) use the recipient's dashboard language. Set it on Profile and the same emails arrive in that language.
• Emails to your customers (a payment receipt, the “new sale” and “new response” alerts) use the form language resolved the same way the form itself is: form → workspace → English. A guest who pays without an account still gets the language your form is set to — there is no profile to ask.

A never-edited notification rule is translated too — you only get your own wording back once you have actually edited that rule, and JomForm never rewrites text you wrote. An unset or unsupported language always falls back to English, never to Malay. Arabic emails are sent right-to-left, and the email declares its own language so a mail client or screen reader reads it correctly.

The subject and the body are judged separately, so editing one of them does not pin the other. If you rewrite only the body, your words are kept and the untouched subject still follows the language above; if you rewrite only the subject, the untouched body still follows it. Only the half you actually typed is treated as yours.

Related: the placeholder reference lists every {{token}} you can use in a subject or body.

Your workspace address, and names that are reserved

A workspace slug becomes your public address: a workspace called acme is served at acme.jomform.com, and your forms live under it. A slug is 3–40 characters of a-z, 0-9 and dashes, it cannot end in jomform, and it must not be a name reserved for JomForm.

Reserved names are the addresses JomForm owns or has to protect. They fall into three groups: infrastructure (www, api, app, mail, s3); JomForm's own product and edge addresses that are already routed, such as docs, mcp, templates and custom; and sensitive names that read as JomForm's own business or support channel, such as support, help, status, billing, admin, account, login, payments and checkout.

The reason is impersonation: an address like billing.jomform.com would let a buyer be asked for card or invoice details under JomForm's name, so a workspace cannot hold it even while JomForm is not using it. If you try one, JomForm tells you the name is reserved (not that your slug was malformed) and asks you to pick another. The same rule applies whether you create the workspace in the dashboard, over the REST API (POST /v1/workspaces — the refusal carries the code reserved_subdomain) or through an AI agent with the create_workspace MCP tool.

Renaming is covered by the same rule, because a rename can move your ADDRESS just as a create can set it. Changing the address of an existing workspace — in Settings → Workspace, over the REST API (PATCH /v1/workspaces/{id}) or through the update_workspace MCP tool — is refused with reserved_subdomain if the new slug is a reserved name, and the workspace keeps the address it had.

Image URLs must be https://

Every image/URL you set — the form logo (set_form_theme), the landing-page hero image and logo (set_workspace_landing_page, or Settings → Storefront), product images (create_product / update_product, or the Products editor) and a form's image block — must be an absolute https:// URL. Uploaded media from the media library already qualifies: upload_media returns an absolute https URL on your own media host, which is accepted everywhere.

A value with any other scheme (data:, http:, javascript:, or a relative path) is rejected when you save it, with a clear message, on both the dashboard and the MCP — the same rule on every path. This is deliberate: the page renders the value into an <img src> for your buyers, and a browser will not load an unsafe scheme. Rejecting it at entry means you see the problem immediately instead of getting a silently missing image on the live page.

Leaving an image field empty is always allowed and means “no image” (or, when updating, “keep the current one”).

Example prompt for your agent

"Apply my Canva design to my JomForm checkout:
1. Upload the logo and hero image from my design (upload_media).
2. Set the form theme to my brand colours, font and layout (set_form_theme).
3. Customise my landing page hero and CTA (set_workspace_landing_page).
4. Add custom CSS for spacing and custom JS to auto-focus the first field (set_form_theme)."

JomForm keeps authority over prices and the payment flow — the agent customizes the look and feel, never the checkout logic. See the MCP tool reference for the full list of tools.