Symbol returned differently using QWIK API compared to html API

Please fill out as many of the following questions as possible so we can help you promptly! If you don’t know how to answer or it does not apply, feel free to remove it or leave it blank.

Builder content link

Builder public api key

Code stack you are integrating Builder with

Reproducible code example
It seems that the QWIK api has issues returning one of the symbols on my product-landing-page called homepage.
Returned by html api

returned by qwik api

This problematic symbol uses an API to fetch its content. It seems that the qwik API returns the default values for the three elements in the symbol. In the html inside the qwik api response, you can see 21 times the text “This is my title”, which is the fallback value for the title underneath every image.

Please let me know if you need more details about the issue.

Hi Vincent,

Sorry about the regression. Let me look into it and get back to you. I will be sure to add an automated test for this so that it will not happen again!

– Misko

1 Like

Hey can you verify that this link works before I push it to production:

Hi @Misko,

Thanks for getting back to me.
I’m a bit confused by how the QA environment is different from prod as on QA the /qwik endpoint returns html, while on prod it returns a JSON object with the html in the html field.
That difference aside, looking at the html returned by the qwik endpoint, all looks good now on QA!


Hi Vincent,

Oops, that is totally on me. Try this link

Hi @Misko ,

Thanks for getting back to me, all looks good now.
Happy even to share that we are now using the QWIK api in production on


Hi Vincent,

Just pushed the fix to production. Usually, it takes about 20 mins for the deploy to go through and for the caches to clear.

Glad to hear that you are using it in production! Could I ask for a set of URLs (Both external as well as URLs) that you are using in production? I will add those to our automated tests so that we don’t break you accidentally again.

Anything else I can do for you? or can answer?

– Misko

Hi Vincent,

I looked into your site a bit and if it is OK with you I would like to offer some suggestions on how to make it faster. Shows a score of 53
diving deeper into it there are two reasons:

  1. The menu system is owned by Next.js. This downloadss and executes a lot of code on the startup. About 1.1 seconds on my top-end mac or 7 seconds on a mobile phone. Getting rid of that would greatly improve the performance. The easiest thing would be to turn the menu into symbol and serve it as a Qwik. Then assemble everything on the client without next.js. But I don’t know your setup so I am not sure what the best way to do this is.
  2. I also notice that you have GoogleTag Manager. This also negatively impacts startup performance. I would suggest moving that into for a faster startup. Similarly, I see that you have some Shopify scripts as well. I am not sure if those are partytown compatible (they should) but moving those over would help as well.

Hope this is useful.

I suggest joining us on discord (

– Misko

Hi @Misko ,
Thanks for getting back to me, your comment about putting the code in production made me realise I accidentally deployed in production my code using the Builder QA endpoint. That has now been fixed.
Thanks as well for both suggestions, I appreciate your feedback.
Regarding the use of Next.js, the framework I’m using is react-storefront which is used to power mainly the shop part of the website (see for example Definitely a good suggestion to try to optimise the bundle size.
Partytown is next on my list.
Which scripts do you think are used by Shopify, because I don’t use that platform at all.

Links to use for your integration tests (staging is probably better as production has a CDN long cache period so you wouldn’t notice a breaking change and later trace it back to a roll out.

Thanks for all the great help!