Tray vs Shopify in 2026: customization, limits and integrations

The Short Answer (BLUF)

Tray is not "too closed to exist". It is closed enough to block exactly what brand stores and ads-driven operations need once they are past the beginning: HTML and JS on the storefront, fine-grained theme customization, and integrations that do not lean on a generic app or on GTM as a crutch.

On the official plans page, Lançamento (Launch) lists customization as visual editor. HTML and CSS appear from Crescimento (Growth) up (Tray plans). Even with HTML unlocked, the official documentation tells you to duplicate the published theme before editing code, support does not assist with those edits, and you cannot create or delete files in pages/, layouts/ and configs/ (edit HTML, editing via HTML).

Shopify, as the useful contrast, delivers a Liquid theme with Theme App Extensions in the editor and Checkout UI Extensions at payment (Theme App Extensions, Checkout UI Extensions). Cost matters, but here it is a consequence of the technical ceiling, not the central thesis.

---

If you run a store on Tray, you have probably already heard one of these sentences from a developer or an agency:

1. "We can change the color and the banner, but that layout rule does not fit in the editor."
2. "The partner's pixel / script only goes in through GTM, and on checkout we cannot guarantee it fires."
3. "For that webhook / custom sync, you need an accredited app and a support ticket."
4. "You cannot edit the live theme; you have to duplicate it, work on the copy and republish."

None of these sentences is "hating on Tray". They are documented limits or side effects of the platform model. The rest of this article organizes those limits along three axes: HTML/JS, theme customization, integrations. Shopify comes in as a contrast where the contrast changes the decision. At the end, costs come in as support for knowing when the ceiling has already become too expensive.

---

1. HTML and JavaScript: what Tray actually unlocks

The plan gate

Before discussing code quality, look at what Tray itself sells:

Source: tray.com.br/planos. If the store is on the entry plan and the brief calls for a landing page with its own HTML, a JS component on the product page or a fine template override, the conversation already starts with a plan upgrade, not in the editor.

The official code editing flow

With HTML unlocked, the path documented by Tray is:

1. Do not edit the published theme.
2. Duplicate the theme.
3. Open Editar HTML (Edit HTML) on the copy.
4. Publish the copy afterwards.

The knowledge base makes it explicit: customer service does not provide assistance with these edits; either you know how to code or you hire someone (How to edit your theme's HTML).

In practice, this creates three operational frictions:

• Slow cycle. Every serious change becomes duplicate → edit → test → publish, instead of a continuous branch/preview as in modern theme workflows.
• Regression risk. Whoever touched the Twig/HTML and removed the platform's required markers breaks a module, SEO or analytics. The theme documentation stresses the standardized structure and the platform's way of working (Understand the theme).
• File ceiling. When editing via HTML, you cannot create or delete files in pages/, layouts/ and configs/; theme installation is limited to 25 (editing via HTML). A custom landing page, a new layout and structural config are not "create the file and you are done".

JavaScript and third-party scripts: GTM as the main door

Tray documents Google Tag Manager as the way to include code without editing the theme HTML, via Configurações → Integrações → Ferramentas Google (Settings → Integrations → Google Tools) (integrate GTM). That is useful for GA4, Ads and pixels. It is also an architectural signal: the storefront is not your playground for free head/body injection.

What usually hurts in operations:

• Meta pixel, affiliate scripts, chat, heatmap and A/B tests compete inside GTM, with firing order, consent and CSP/nonce.
• Checkout, add-to-cart and purchase events depend on a stable dataLayer. If the payment page or the account flow changes, tags break without the merchant noticing.
• Scripts that need to live inside the template (above the fold, blocking CLS, reading the product's Liquid/Twig) do not fit the "GTM only" model.

The Shopify contrast. In the theme, Liquid + assets + Theme App Extensions let you inject UI and logic into the storefront through the editor, without the merchant pasting code in the middle of the theme (Theme App Extensions). For checkout, the official route is a Checkout UI Extension, not a loose script at the payment step (Checkout UI Extensions). The point is not "Shopify lets you mess up the head". It is that the platform separates storefront and checkout with first-class extensions, instead of pushing almost everything into GTM + duplicated HTML.

---

2. Theme and storefront customization

Twig + visual editor: freedom on rails

Tray themes use Twig with HTML, CSS, JavaScript and JSON, in a directory structure defined by the platform (Understand the theme). You can build a niche theme and sell it in the theme store. It also means the store runs on Tray's rails, not on a free front-end framework.

The visual editor (drag and drop of sections in Tema Padrão 3.0 and equivalents) handles these well:

• banners, product showcases, brands, footer, info bar;
• reordering sections without a developer;
• appearance tweaks for merchants without HTML.

It does not handle these well:

• product layouts with proprietary UX (fit finder, configurator, kit builder);
• campaign pages with a structure outside what the theme exposes;
• components that depend on client-side state beyond what the theme/storefront API exposes;
• an in-house design system with typography, motion and components shared across landing pages, collections and checkout.

What the merchant feels day to day

The right question is not "Does Tray have good-looking themes?". It does. The question is: how much of the brand brief fits in the editor and in the allowed Twig without turning into a hack.

When the answer is "less than half", the store is already paying an agency to work around the platform, not to accelerate the brand.

---

3. Integrations: API, webhooks, apps, checkout and pixel

API and webhooks

Tray has a developer ecosystem and an API. The notification system (webhook) sends a POST as application/x-www-form-urlencoded with seller_id, scope_id, scope_name, act, app_code and url_notification to the URL registered in the accredited app (Tray Developers).

Practical implications:

• A "real" integration goes through an app, not through a loose endpoint the merchant pastes into the admin.
• The payload is not the typed JSON most engineering teams expect by default; a wrong parse = a silent sync.
• Scopes beyond the basics (order, stock, product, etc.) often require enablement and retry discipline: if the URL does not respond with a 200, the platform resends.

That serves ERPs and marketplace hubs. It gets heavy when you want:

• home-grown automation (n8n, your own worker) without a published app;
• granular storefront events (view_item, begin_checkout) with a stable contract;
• a checkout extension with its own UI.

The Shopify contrast. Admin API (REST/GraphQL), JSON webhooks, app extensions and a mature App Store. For the storefront, Theme App Extensions; for payment, Checkout UI Extensions. Engineering cost drops because the contract is public, versioned and built for third-party apps.

Checkout: the black hole of customization

Checkout is where the "almost unlocked" HTML/JS in the theme stops applying.

On Tray, typical operations handle payment, shipping and anti-fraud with what the platform and native apps provide. Customizing step by step, an extra tax field, native upsell at payment or trust UI at the critical step usually becomes:

• a Tray marketplace app;
• a script via GTM with a fragile trigger;
• or "can't be done".

On Shopify, checkout customization moves toward official extensions, not toward an eternal checkout.liquid. Theme app blocks do not render on checkout pages; the documented route is the Checkout UI Extension (Theme App Extensions, Checkout UI Extensions).

For a store with heavy paid traffic, this matters because the documented average abandonment rate is 70.22%, and 48% abandon because of extra costs that are too high or revealed late (Baymard). If you do not control the experience of the payment step, you are optimizing ads for a funnel the platform locks.

Pixel, head/body and marketing scripts

Operational summary on Tray:

1. Official preference: GTM in the admin, without the theme HTML (GTM).
2. Theme HTML: only with the right plan + duplication + care with the Twig structure.
3. Checkout and authenticated areas: validate firing in practice, not just in GTM Preview.

If the media buyer needs CAPI + pixel + funnel events with deduplication, the implementation budget rises fast. Not because "Tray has no GTM", but because GTM does not replace an extensible storefront and checkout.

---

4. Real costs: support, not thesis

Monthly fees and commissions matter. They just do not decide on their own when the problem is an engineering ceiling.

Official reference (do not compare just the sticker price)

The invisible cost on Tray, in this article, is something else:

• Agency hours to work around the editor/Twig.
• Apps that exist because the theme does not deliver the rule.
• GTM rework with every funnel change.
• Lost experiments: checkout UX A/B tests that simply do not run.

If the monthly sum of "technical workarounds" already exceeds the platform difference, migration is no longer a matter of stack taste and has become damage control.

---

5. When to stay on Tray and when Shopify makes sense

Stay on Tray if

• Your own site is a support channel and sales live on marketplaces.
• The visual editor + official apps cover the brand brief.
• You do not depend on custom JS on the product page/checkout or on a home-grown webhook.
• The team accepts GTM as the main door for scripts.

Seriously evaluate Shopify if

• The brand demands a storefront off the Tray theme's rails.
• You need app extensions in the right place on the page, without patching the published HTML.
• Checkout and conversion events are the core of your ads ROI.
• The engineering team wants API/webhooks with a modern contract and versioned apps.
• You already pay a "workaround fee" every month (agency + apps + fragile GTM).

Rule of thumb: if the customization and integration brief does not fit within what Tray documents (plan, duplicate theme, locked folders, GTM, accredited app), the discussion about a monthly fee in dollars is secondary.

---

6. Checklist before deciding

Answer with evidence from the store, not with gut feeling:

1. Does your Tray plan unlock HTML/CSS or only the visual editor? (plans)
2. How many times last quarter did you duplicate the theme just to publish HTML?
3. Which critical scripts depend only on GTM, and which broke at checkout?
4. Is there an integration that stalled because it needed an accredited app / webhook scope?
5. How much do you spend per month on agency/apps just to work around theme limits?
6. Is your own site the sales engine, or do marketplaces still carry 80%+?

If 2 to 5 hurt and the answer to 6 is "own site", the ceiling is already charging you.

---

Conclusion

Tray remains strong for Brazilian businesses starting out and for marketplace-first operations. The limit that weighs most in 2026 is not the sticker price of the monthly fee: it is the combo of HTML/JS behind a plan gate with a copy workflow, a Twig theme on the platform's rails, and integrations that push scripts into GTM and automation into an accredited app.

Shopify stands out where operations need a truly extensible storefront and checkout. Costs come into the equation once you admit the technical ceiling.

If you want a diagnosis of your store (what fits in the current theme vs. what is already a workaround), open Contact at oailton.dev/en/contato with your platform, plan and two examples of customizations that stalled. I will give you the verdict based on the brief, not on a slogan.