How to Embed a Zendesk Form on Your Site
You want to embed a Zendesk form on your own site rather than sending people to a help centre subdomain. There are three ways and they're not close to equivalent.
Three ways to embed a Zendesk form
Most teams should start with the first, and a meaningful minority end up at the third. The middle option is the one that looks easiest and disappoints most often.
What each route costs you
| Web widget | Iframe | Own form on the API | |
|---|---|---|---|
| Sits inside your page layout | Sort of | ||
| Full control of styling | |||
| Conditional fields work | You build them | ||
| Spam protection included | |||
| Build effort | An hour | An hour | Days |
| Breaks when Zendesk changes |
The widget route to embed a Zendesk form
The widget can be configured to offer a contact form, with help centre search in front of it if you want deflection. It's maintained by Zendesk, it inherits your ticket forms and field permissions, and it handles spam and validation without you thinking about either.
What it won't do is sit in the middle of your page. It's a launcher in a corner that opens a panel. You can open it from your own button through the widget JavaScript API, which gets you most of the way to feeling embedded, and that trick is badly underused.
If your requirement is "a support form on our contact page" rather than "a form in our exact design system", this is almost certainly the answer, and the other two sections are a way of spending a fortnight to prove it.
The iframe route, and why to be careful
Dropping the submit a request page into an iframe is the tempting shortcut. It works, in the narrow sense that a form appears.
What you inherit is a page you don't control inside a frame you do. The height is wrong on mobile unless you fight it. The theme styling of your help centre shows through, so it looks like a different site embedded in your site, because that's exactly what it is. Redirects after submission land inside the frame. And anything Zendesk changes about that template changes your page without warning.
It also complicates sign-in, since cookies inside a third-party frame are treated with increasing suspicion by browsers. If your form depends on the customer being recognised, test it properly in Safari before you commit to anything.
Use it for an internal page nobody will judge. Don't use it on a marketing site.
Rolling your own on the Requests endpoint
Your form, your markup, your validation, posting to the Zendesk Requests API to create the ticket. This is the right answer when the form is genuinely part of your product experience rather than an afterthought on a contact page.
Two things to get right, and one of them is a security issue rather than a preference.
Use the Requests endpoint with end-user credentials, not the Tickets endpoint with an admin token. An API token that can read every ticket you have should never exist in code that ships to a browser. If you find one in a public bundle, treat it as compromised and rotate it today, not on Friday.
Post from your own server, not from the page. Your form submits to your backend, your backend talks to Zendesk. That gives you somewhere to keep the credential, somewhere to add rate limiting, and somewhere to run a spam check before anything reaches your queue.
And you now own everything the platform was doing for you: required field logic, conditional fields, attachments, validation messages, and the confirmation the customer expects. That's the real cost, and it arrives six months later when somebody adds a ticket field and nobody updates the form.
Spam, which arrives immediately
A public form on a public domain gets found within days. The widget and the help centre form have protections in front of them. Your own form has whatever you built, which on day one is nothing.
A honeypot field plus a simple rate limit stops most of it. Beyond that, add a visible challenge only if you must, since every challenge costs you real submissions from real people who are already annoyed. And keep an eye on the suspended tickets view, because the alternative is discovering the problem through your agents.
Frequently asked questions
Can I put a Zendesk form on my website?
Yes, three ways. A Zendesk embedded form via iframe is quickest, the widget is friendliest, and building your own against the Requests endpoint gives you full control. To embed a Zendesk contact form and keep spam out, use the widget or add a captcha to your own build.
Can I embed a Zendesk form directly in my page?
Not as native markup. The supported routes are the web widget, an iframe of the request page, or building your own form against the Requests API.
Is iframing the submit a request page a bad idea?
On anything customer-facing, usually yes. Height, styling, redirects after submission and third-party cookie handling all cause problems you do not control.
Which API creates a ticket from a public form?
The Requests endpoint with end-user credentials. Never ship an admin API token in browser code.
Do conditional fields work in an embedded form?
In the widget and the help centre page, yes. In your own form you are implementing that logic yourself, which is a large part of the build cost.
Every extra entry point adds duplicates
A form on your site plus email plus chat means the same request arrives more than once. Ticket Merger merges the copies.
Start free trial14-day free trial. No credit card required.