You can use your own JavaScript, HTML and CSS in your surveys. For security reasons, however, customers cannot add this code themselves in the app. You send us the ready-made code and tell us which survey it belongs to, and our team implements it on our side.

Our platform offers a wide range of built-in options: themes, colors, fonts, logos, question layouts and branching logic. In most cases these are more than enough to make your survey look and behave exactly the way you want.

There are situations, though, where the standard settings fall short. For example, you may want to:

  • match the survey to detailed brand guidelines (custom spacing, animations, unusual graphic elements),
  • add your own analytics script or tracking pixel,
  • insert an extra HTML block, such as a banner, a footer with legal information or an embedded external element,
  • introduce custom interface behavior that the built-in features don't support.

In cases like these, we're here to help. Below we explain why implementation happens on our side and how to request it, step by step.

Why we implement the code ourselves

Custom code runs directly in the browsers of the people filling in your survey. That's why every snippet reaches a survey only through our team — a deliberate decision that protects you, your respondents and the platform as a whole.

As a SaaS tool, we serve many organizations on shared infrastructure. A bug or vulnerability in a single script could affect not just one survey, but the stability and reputation of the entire service. A controlled implementation process prevents that.

The key reasons behind this approach:

  • Protecting respondent data. A careless or malicious script could intercept answers or personal data, or send them to unknown servers. We check where the code sends data and which resources it loads.
  • Preventing XSS attacks. Letting anyone paste JavaScript freely into the app is a classic entry point for cross-site scripting. If an account were ever compromised, an attacker could use it to infect a survey. Implementing code on our side closes that door.
  • GDPR and security policy compliance. Third-party scripts (such as analytics) may require user consent or a data processing agreement. We review code with this in mind too and flag potential risks.
  • Stability and performance. Faulty code can block survey submissions, slow down page loading or break the layout on mobile devices. We test the code before it goes live.
  • Control and auditability. We know exactly which code runs in which survey, who requested it and when it was added. This makes troubleshooting easier and lets us roll changes back if needed.
  • Compatibility with platform updates. We know how our surveys are built, so we can tell you whether your code is likely to break after future interface changes.

This model doesn't limit what you can do — you can still use your own code. The only thing that changes is who actually puts it in place.

How to request an implementation, step by step

On your side, it comes down to three things: preparing the code, pointing us to the survey and sending the request. We take care of the rest.

  1. Prepare the code. Get your JavaScript, HTML and/or CSS ready and tested. Ideally, send it as an attachment (a .js, .html, .css or .txt file) or as a text block - not as a screenshot.
  2. Identify the survey. Give us the survey name along with its link or ID. If the code should go into several surveys, list all of them. We only implement code in the surveys named in the request.
  3. Describe the purpose and placement. Briefly explain what the code should do and where it should run: across the whole survey, on a specific page, on a particular question, on the thank-you page, and so on.
  4. Send the request. Send all of this to our support team (you'll find the contact details at the end of this article). The request should come from someone authorized to manage the account.
  5. Our review. We review the code for security, platform compatibility and its impact on how the survey works. If anything raises concerns, we'll get back to you with questions or suggested changes.
  6. Implementation and testing. Once the review is complete, we add the code to the specified survey and check that it works correctly.
  7. Confirmation. We let you know when the implementation is done. Please also check the survey yourself before sharing it with respondents.

Changing or removing code works the same way: send a request naming the survey and including the new version of the code (or asking us to remove it).