Tray vs Shopify em 2026: Limites de HTML, Personalização e Integração (e Quando Migrar)

O Resumo Direto (BLUF)

A Tray não é "fechada demais para existir". É fechada o suficiente para travar exatamente o que loja de marca e operação de ads precisam depois do começo: HTML e JS no storefront, personalização fina de tema, e integrações que não dependam de app genérico ou de GTM como muleta.

Na página oficial de planos, o Lançamento lista personalização como editor visual. HTML e CSS aparecem a partir do Crescimento (planos Tray). Mesmo com HTML liberado, a documentação oficial manda duplicar o tema publicado antes de editar código, o suporte não auxilia essas edições, e não dá para criar ou excluir arquivos em pages/, layouts/ e configs/ (editar HTML, edição via HTML).

A Shopify, no contraste útil, entrega tema em Liquid com Theme App Extensions no editor e Checkout UI Extensions no pagamento (Theme App Extensions, Checkout UI Extensions). Custo importa, mas aqui ele é consequência do teto técnico, não a tese central.

---

Se você opera na Tray, é comum já ter ouvido uma destas frases de um desenvolvedor ou de uma agência:

1. "Dá para mudar a cor e o banner, mas essa regra de layout não cabe no editor."
2. "O pixel / script do parceiro só sobe via GTM, e no checkout a gente não garante o disparo."
3. "Para esse webhook / sync custom, precisa de app credenciado e chamado no suporte."
4. "Não dá para editar o tema que está no ar; tem que duplicar, mexer na cópia e republicar."

Nenhuma dessas frases é "ódio à Tray". São limites documentados ou efeitos colaterais do modelo de plataforma. O resto deste texto organiza esses limites em três eixos: HTML/JS, personalização de tema, integrações. A Shopify entra como contraste onde o contraste muda a decisão. No fim, custos entram como apoio para saber quando o teto já está caro demais.

---

1. HTML e JavaScript: o que a Tray libera de verdade

O portão do plano

Antes de discutir qualidade de código, veja o que a própria Tray vende:

Fonte: tray.com.br/planos. Se a loja está no plano de entrada e o brief pede landing com HTML próprio, componente JS no PDP ou override fino de template, a conversa já começa no upgrade de plano, não no editor.

O fluxo oficial de edição de código

Com HTML liberado, o caminho documentado pela Tray é:

1. Não editar o tema publicado.
2. Duplicar o tema.
3. Abrir Editar HTML na cópia.
4. Publicar a cópia depois.

A base de conhecimento deixa explícito: o atendimento não presta auxílio para essas edições; ou você sabe programar, ou contrata alguém (Como editar o HTML do seu tema).

Na prática, isso gera três atritos operacionais:

• Ciclo lento. Toda mudança séria vira duplicar → editar → testar → publicar, em vez de um branch/preview contínuo como em fluxos modernos de tema.
• Risco de regressão. Quem mexeu no Twig/HTML e removeu marcadores obrigatórios da plataforma quebra módulo, SEO ou analytics. A documentação de temas enfatiza estrutura padronizada e padrão de funcionamento da plataforma (Entenda o tema).
• Teto de arquivos. Na edição via HTML, não é possível criar ou excluir arquivos em pages/, layouts/ e configs/; a instalação de temas é limitada a 25 (edição via HTML). Landing page custom, layout novo e config estrutural não são "crie o arquivo e pronto".

JavaScript e scripts de terceiros: GTM como porta principal

A Tray documenta o Google Tag Manager como caminho para incluir códigos sem editar o HTML do tema, via Configurações → Integrações → Ferramentas Google (integrar GTM). Isso é útil para GA4, Ads e pixels. Também é um sinal de arquitetura: o storefront não é o seu playground de head/body injection livre.

O que costuma doer na operação:

• Pixel Meta, scripts de afiliado, chat, heatmap e A/B test competem no GTM, com ordem de disparo, consentimento e CSP/nonce.
• Eventos de checkout, add-to-cart e purchase dependem de dataLayer estável. Se a página de pagamento ou o fluxo de conta mudam, tags quebram sem o lojista perceber.
• Scripts que precisam viver dentro do template (acima da dobra, bloqueando CLS, lendo Liquid/Twig do produto) fogem do modelo "só GTM".

Contraste Shopify. No tema, Liquid + assets + Theme App Extensions permitem injetar UI e lógica no storefront pelo editor, sem o lojista colar código no meio do tema (Theme App Extensions). Para checkout, a via oficial é Checkout UI Extension, não script solto na etapa de pagamento (Checkout UI Extensions). O ponto não é "Shopify deixa bagunçar o head". É que a plataforma separa storefront e checkout com extensões de primeira classe, em vez de empurrar quase tudo para GTM + HTML duplicado.

---

2. Personalização de tema e storefront

Twig + editor visual: liberdade com trilho

Temas Tray usam Twig com HTML, CSS, JavaScript e JSON, em estrutura de diretórios definida pela plataforma (Entenda o tema). Dá para construir tema de nicho e vender na loja de temas. Também significa: a loja anda no trilho Tray, não num framework front livre.

O editor visual (drag and drop de seções no Tema Padrão 3.0 e equivalentes) resolve bem:

• banners, vitrines, marcas, rodapé, barra de informações;
• troca de ordem de seções sem dev;
• ajustes de aparência para lojista sem HTML.

Ele não resolve bem:

• layout de produto com UX proprietária (fit finder, configurador, kit builder);
• páginas de campanha com estrutura fora do que o tema expõe;
• componentes que dependem de estado no cliente além do que o tema/API da vitrine expõe;
• design system próprio com tipografia, motion e componentes compartilhados entre LP, coleção e checkout.

O que o lojista sente no dia a dia

A pergunta certa não é "Tray tem tema bonito?". Tem. A pergunta é: quanto do brief de marca cabe no editor e no Twig permitido sem virar gambiarra.

Quando a resposta for "menos da metade", a loja já está pagando agência para contornar a plataforma, não para acelerar a marca.

---

3. Integrações: API, webhooks, apps, checkout e pixel

API e webhooks

A Tray tem ecossistema de desenvolvedores e API. O sistema de notificações (webhook) envia POST em application/x-www-form-urlencoded com seller_id, scope_id, scope_name, act, app_code e url_notification para a URL cadastrada no aplicativo credenciado (Tray Developers).

Implicações práticas:

• Integração "de verdade" passa por app, não por um endpoint solto que o lojista cola no painel.
• O payload não é o JSON tipado que a maior parte dos times de engenharia espera por padrão; parse errado = sync mudo.
• Escopos além do básico (pedido, estoque, produto, etc.) frequentemente exigem habilitação e disciplina de retry: se a URL não responder 200, a plataforma reenvia.

Isso serve ERP e marketplace hub. Fica pesado quando você quer:

• automação caseira (n8n, worker próprio) sem app publicado;
• eventos granulares de storefront (view_item, begin_checkout) com contrato estável;
• extensão de checkout com UI própria.

Contraste Shopify. Admin API (REST/GraphQL), webhooks JSON, app extensions e um App Store maduro. Para a vitrine, Theme App Extensions; para o pagamento, Checkout UI Extensions. O custo de engenharia cai porque o contrato é público, versionado e feito para app de terceiros.

Checkout: o buraco negro da personalização

Checkout é onde HTML/JS "quase liberados" no tema deixam de valer.

Na Tray, a operação típica resolve pagamento, frete e antifraude com o que a plataforma e os apps nativos entregam. Customizar passo a passo, campo fiscal extra, upsell nativo no pagamento ou UI de trust na etapa crítica costuma virar:

• app de marketplace Tray;
• script via GTM com acionador frágil;
• ou "não dá".

Na Shopify, customização de checkout caminha para extensões oficiais, não para checkout.liquid eterno. Theme app blocks não renderizam nas páginas de checkout; a via documentada é Checkout UI Extension (Theme App Extensions, Checkout UI Extensions).

Para loja com tráfego pago alto, isso importa porque abandono médio documentado fica em 70,22%, e 48% abandonam por custos extras altos ou revelados tarde (Baymard). Se você não controla a experiência da etapa de pagamento, está otimizando anúncio para um funil que a plataforma trava.

Pixel, head/body e scripts de marketing

Resumo operacional na Tray:

1. Preferência oficial: GTM no painel, sem HTML do tema (GTM).
2. HTML do tema: só com plano adequado + duplicação + cuidado com estrutura Twig.
3. Checkout e áreas autenticadas: validar disparo na prática, não só no Preview do GTM.

Se o gestor de tráfego precisa de CAPI + pixel + eventos de funil com deduplicação, orçamento de implementação sobe rápido. Não porque "Tray não tem GTM", mas porque GTM não substitui storefront e checkout extensíveis.

---

4. Custos reais: apoio, não tese

Mensalidade e comissão importam. Só não decidem sozinhas quando o problema é teto de engenharia.

Referência oficial (não compare só o sticker price)

O custo invisível na Tray, neste artigo, é outro:

• Horas de agência para contornar editor/Twig.
• Apps que existem porque o tema não entrega a regra.
• Retrabalho de GTM a cada mudança de funil.
• Perda de experimento: A/B de UX no checkout que simplesmente não roda.

Se a soma mensal de "contorno técnico" já supera a diferença de plataforma, a migração deixou de ser gosto de stack e virou contenção de prejuízo.

---

5. Quando ficar na Tray e quando a Shopify faz sentido

Continue na Tray se

• O site próprio é apoio e a venda mora em marketplace.
• Editor visual + apps oficiais cobrem o brief de marca.
• Você não depende de JS custom no PDP/checkout nem de webhook caseiro.
• O time aceita GTM como porta principal de scripts.

Avalie Shopify com seriedade se

• A marca exige storefront fora do trilho do tema Tray.
• Você precisa de extensões de app no lugar certo da página, sem patch no HTML publicado.
• Checkout e eventos de conversão são o centro do ROI de ads.
• O time de engenharia quer API/webhook com contrato moderno e app versionado.
• Você já paga "taxa de contorno" todo mês (agência + apps + GTM frágil).

Regra prática: se o brief de personalização e integração não cabe no que a Tray documenta (plano, duplicar tema, pastas travadas, GTM, app credenciado), a discussão de mensalidade em dólar é secundária.

---

6. Checklist antes de decidir

Responda com evidência da loja, não com feeling:

1. Seu plano Tray libera HTML/CSS ou só editor visual? (planos)
2. Quantas vezes no último trimestre vocês duplicaram tema só para publicar HTML?
3. Quais scripts críticos dependem só de GTM, e quais quebraram no checkout?
4. Existe integração que travou porque precisava de app credenciado / escopo de webhook?
5. Quanto você gasta por mês em agência/apps só para contornar limite de tema?
6. O site próprio é o motor de venda, ou marketplace ainda carrega 80%+?

Se 2 a 5 doerem e a 6 for "site próprio", o teto já está cobrando.

---

Conclusão

A Tray continua forte no começo brasileiro e em operação marketplace-first. O limite que mais pesa em 2026 não é o sticker da mensalidade: é o combo HTML/JS com portão de plano e fluxo de cópia, tema Twig no trilho da plataforma, e integrações que empurram script para GTM e automação para app credenciado.

A Shopify contrasta onde a operação precisa de storefront e checkout extensíveis de verdade. Custos entram na conta depois que você admite o teto técnico.

Se quiser o diagnóstico da sua loja (o que cabe no tema atual vs. o que já é contorno), abra Contato em oailton.dev/contato com plataforma, plano e dois exemplos de customização que travaram. Eu devolvo o veredito em cima do brief, não em cima de slogan.