Denaryx
Nesta documentação

API Admin › Guias

Testar numa loja de teste

A loja de teste é uma loja da Denaryx em que nenhum dinheiro de verdade circula. Toda loja nova nasce assim, em construção, até a Denaryx publicá-la: é nela que o ERP testa a integração e a agência monta o tema antes de a loja vender.

Por que na produção

A loja de teste fica na mesma instalação das lojas reais: o mesmo endereço da API (https://api.denaryx.com/admin/2026-10), a mesma versão, os mesmos limites, os mesmos webhooks e o mesmo servidor MCP. O que funciona nela funciona igual numa loja real, e não há outro endereço nem outro tipo de token para trocar quando a loja entra no ar.

O que muda é só o que envolveria dinheiro, compradores de verdade ou buscadores (ver O que não acontece).

Como conseguir uma

Toda loja nova já nasce de teste, em construção. Só a Denaryx publica a loja (ver Quando a loja vira real) e só ela marca como de teste uma loja que já vende.

  1. Peça a loja à Denaryx, com o e-mail de quem vai ser o dono dela.
  2. Chega o convite "Sua loja na Denaryx está liberada". Crie a conta com esse e-mail e crie a loja no painel.
  3. A loja nasce em construção: o painel mostra, no topo, o aviso "Loja em construção".

Se a loja de teste já existe (a do seu cliente), peça ao dono ou ao gerente dela que crie uma integração para o seu sistema, em Configurações › Integrações (ver Autenticação), ou que convide você para a equipe, em Configurações › Equipe. Quem está na equipe recebe os e-mails da loja (ver abaixo).

O que funciona como numa loja real

  • o painel inteiro: catálogo, coleções, marcas, estoque, preços, cupons, pedidos, equipe;
  • os temas: o editor, o código, o CLI e o tema no GitHub;
  • a API Admin, com o token de integração e os escopos de sempre, os eventos e os webhooks;
  • o servidor MCP e as skills para agentes;
  • a vitrine, o carrinho, o checkout e a área do cliente;
  • a medição no navegador: o Tag Manager e os pixels da loja recebem os eventos como numa loja real (ver o dataLayer). A compra que a plataforma envia pelo servidor não entra nos relatórios: ao GA4 ela vai pelo servidor de validação, e à Meta e ao TikTok ela não vai.

O pagamento

Nenhum pagamento da loja de teste é real. Há dois caminhos: o pagamento simulado, sem provedor nenhum, e a conta de teste de um provedor.

O pagamento simulado

Sem conta de pagamento conectada, a loja recebe pelo pagamento simulado. Ele não passa por banco nem por provedor, e não pede dado nenhum de cartão.

  • Cartão: no checkout, o cartão de teste não tem número, validade nem código. Quem testa escolhe o que o banco responde:
    • Aprovado na hora: o pedido fica pago (paid), com o pagamento approved;
    • Recusado pelo banco: o pagamento fica declined, e o pedido continua aguardando pagamento (pending_payment). A página do pedido oferece pagar com Pix;
    • Em análise: o pagamento fica authorized e o pedido continua aguardando pagamento, como o cartão à espera da análise de risco. Aprove na página do pedido, como o Pix.
  • Pix e boleto: o checkout gera o Pix (e o boleto, se ele estiver ligado em Configurações › Pagamentos), que ninguém paga. Na página do pedido, o botão Aprovar o pagamento de teste faz o papel do banco: o pedido fica pago pelo mesmo caminho de um pagamento de verdade, com os e-mails, o webhook order.paid e o estoque.

Pela API, POST /orders/{id}/mark_paid também passa a pago o pedido que aguarda pagamento, como num pagamento recebido fora da plataforma (ver Pedidos).

As contas de teste dos provedores

Para testar com o próprio provedor, conecte uma conta de teste em Configurações › Pagamentos:

  • Mercado Pago: um vendedor de teste, criado nas contas de teste do painel de desenvolvedores do Mercado Pago. A conta de teste do Mercado Pago não tem chave Pix, então só o cartão funciona por ela;
  • Cielo: o ambiente Sandbox (testes da Cielo), com as credenciais do sandbox.

Os cartões de teste são os da documentação de cada provedor. Com uma conta de teste conectada, o checkout cobra por ela, e não pelo pagamento simulado.

A conta de verdade também conecta na loja de teste, mas não cobra enquanto a loja for de teste: a loja recebe pelo pagamento simulado. Ela passa a cobrar quando a loja vira real (ver Quando a loja vira real).

O pedido de teste

Todo pedido feito numa loja de teste traz "test": true, na API Admin (ver o objeto pedido) e no data dos webhooks de pedido. A marca vem da loja quando o pedido é criado e não muda depois, nem quando a loja vira real. No painel, o pedido tem a etiqueta "Pedido de teste".

POST /webhooks/denaryx HTTP/1.1
Content-Type: application/json
Denaryx-Event-Type: order.paid
Denaryx-Api-Version: 2026-10

{
  "id": "2f6c0a8e-...",
  "type": "order.paid",
  "created_at": "2026-10-23T18:02:10.000Z",
  "api_version": "2026-10",
  "data": {
    "id": "6c1d0a52-...",
    "number": 1001,
    "status": "paid",
    "payment": {
      "method": "credit_card",
      "status": "approved",
      "amount": 7180,
      "installments": 1,
      "refunded_at": null,
      "created_at": "2026-10-23T18:02:00.000Z"
    },
    "paid_at": "2026-10-23T18:02:10.000Z",
    "test": true,
    ...
  }
}

Use o test para separar os pedidos de teste no seu sistema: não emitir nota fiscal de verdade por eles, não separar estoque físico, não somar no faturamento. O GET /shop não diz se a loja é de teste: o que vale é o test de cada pedido.

Enquanto a loja é de teste, os relatórios da própria loja, no painel e em GET /reports/sales, contam os pedidos de teste como os outros. Quando ela vira real, eles saem das vendas.

O que não acontece

  • E-mail para fora da equipe: os e-mails da loja (os do pedido para quem comprou, os da área do cliente, os avisos à equipe) só saem para quem é da equipe da loja ou tem convite para ela, com [Teste] no começo do assunto. Para os outros endereços, a mensagem não sai. Para receber os e-mails de quem compra, compre com o seu e-mail, de quem está na equipe. Os webhooks não são e-mails: saem para o endereço cadastrado, como numa loja real.
  • Buscadores: a vitrine responde o robots.txt fechado, não tem sitemap nem feed do Google, e toda página leva X-Robots-Tag: noindex, nofollow. A vitrine não tem faixa de aviso, para o tema ser avaliado como ele é; o checkout avisa que a loja é de teste.
  • Domínio próprio: a loja de teste fica no endereço dela na plataforma (o storefront_url de GET /shop). O domínio próprio só é liberado depois que ela vira real.
  • Números da plataforma: as vendas da loja de teste não entram nos números da Denaryx.
  • Etiqueta de frete: a compra de etiqueta do Melhor Envio não está disponível na loja de teste, porque a etiqueta é paga de verdade. A cotação do frete funciona, no checkout e no painel. Para testar o rastreio, informe o código em POST /orders/{id}/ship.

Roteiro de ponta a ponta

Um caminho completo do ERP, da integração ao pedido enviado. Troque dnxa_... pelo seu token.

1. A integração

Em Configurações › Integrações, crie uma integração com write_products e write_orders (que incluem a leitura de produtos e de pedidos) e copie o token. Confira:

curl https://api.denaryx.com/admin/2026-10/token \
  -H "Authorization: Bearer dnxa_..."

2. O webhook

Cadastre um endereço https do seu servidor para os eventos de pedido e guarde o secret da resposta, que aparece uma vez só (ver A assinatura):

curl -X POST https://api.denaryx.com/admin/2026-10/webhooks \
  -H "Authorization: Bearer dnxa_..." \
  -H "Content-Type: application/json" \
  -d '{"url": "https://erp.exemplo.com.br/webhooks/denaryx", "events": ["order.created", "order.paid", "order.shipped"]}'

POST /webhooks/{id}/test manda um evento de teste para conferir o endereço.

3. O produto

Cadastre um produto com estoque, com uma Idempotency-Key nova (ver Escrita repetível):

curl -X POST https://api.denaryx.com/admin/2026-10/products \
  -H "Authorization: Bearer dnxa_..." \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: 3f1c9a52-0d7e-4b8a-9c61-2e5f7a1d4b90" \
  -d '{"title": "Camiseta de Teste", "variants": [{"sku": "TESTE-1", "price": 4990, "inventory_quantity": 10}]}'

O produto aparece na vitrine em <storefront_url>/produtos/<handle>, com o handle da resposta.

4. O pedido

Na vitrine, ponha o produto no carrinho e feche o pedido com o seu e-mail. No pagamento, escolha o cartão de teste Aprovado na hora. Com o Pix, aperte Aprovar o pagamento de teste na página do pedido.

5. O webhook do pedido pago

O seu servidor recebe o order.created e o order.paid, com "test": true e "status": "paid" no data. Confira a assinatura antes de usar o corpo. Se uma entrega se perder, o pedido está em GET /orders?updated_at_min=... e o evento em GET /events.

6. A situação do pedido

Separe e envie pela API:

curl -X POST https://api.denaryx.com/admin/2026-10/orders/6c1d0a52-.../prepare \
  -H "Authorization: Bearer dnxa_..."

curl -X POST https://api.denaryx.com/admin/2026-10/orders/6c1d0a52-.../ship \
  -H "Authorization: Bearer dnxa_..." \
  -H "Content-Type: application/json" \
  -d '{"tracking_code": "AA123456789BR"}'

Chega o order.shipped, e o e-mail de pedido enviado vai para o seu endereço, com [Teste] no assunto, se você está na equipe da loja. Depois, POST /orders/{id}/deliver marca como entregue.

Quando a loja vira real

Quando a loja for vender de verdade, peça à Denaryx para torná-la uma loja real: só ela desmarca a loja de teste. Antes de pedir:

  • conecte a conta de verdade do gateway em Configurações › Pagamentos (o Mercado Pago com a sua conta, ou a Cielo em produção). Ela conecta na loja de teste, mas só cobra depois da troca;
  • tire a conta de teste: no Mercado Pago, conectar a conta de verdade já troca o vendedor de teste; na Cielo, conecte de novo com as credenciais de produção.

A Denaryx não torna real a loja sem a conta de verdade conectada, nem com uma conta de teste: a loja publicada sem gateway não vende, e com a conta de teste cobraria de mentira.

Na troca:

  • o pagamento simulado e o cartão de teste saem do checkout, e a conta de verdade passa a cobrar;
  • os e-mails voltam a sair para os compradores, sem o [Teste] no assunto;
  • a vitrine abre para os buscadores, com o sitemap e o feed do Google, e o domínio próprio pode ser liberado;
  • a loja continua a mesma, com o catálogo, o tema, a equipe, as integrações e os webhooks.

Os pedidos feitos enquanto ela era de teste ficam na loja, com "test": true e a etiqueta Teste no painel, mas saem das vendas: do Início, dos relatórios, de GET /reports/sales, dos totais dos clientes e dos carrinhos recuperados. Cancele os que ficaram em aberto.