Como identificar a transportadora e o serviço do pedido no ERP, na API e na página do pedido

Como identificar a transportadora e o serviço do pedido no ERP, na API e na página do pedido

Quando o pedido entra na Shopify, o frete chega como um nome e um valor: “Jadlog Package, R$ 24,90”. Pra quem despacha, isso basta. Pra quem integra com ERP, não: o Bling ou o Tiny precisam saber qual transportadora emitir, qual serviço, e às vezes qual campanha justificou o valor. E o cliente, na página do pedido, só vê o nome do frete.

O Cota Frete resolve isso gravando esses dados no próprio pedido, como atributos do pedido. Não tem tela nem configuração: acontece em todo pedido cujo frete saiu do Cota Frete, em qualquer plano. Dali os dados ficam disponíveis pro ERP, pra API e pro Liquid do tema e dos e-mails.

O que o app grava no pedido

AtributoO que éExemplo
cotafrete_transportadoraA transportadora por trás do serviço escolhidoCorreios
cotafrete_servicoO nome do serviço como a transportadora entregaSEDEX
cotafrete_codigo_servicoCódigo interno do serviço, que nunca mudacorreios_03220
cotafrete_previsao_entregaData prevista de entrega calculada na cotação27/08/2026
cotafrete_descontoTítulo da campanha de desconto que se aplicou, se houveFrete Grátis Inverno

Alguns detalhes:

  • cotafrete_transportadora é a transportadora real mesmo quando o cliente viu outro nome. Se você usa agrupamento de frete e o cliente escolheu “Econômico”, o atributo diz qual transportadora ganhou aquela cotação.
  • cotafrete_desconto aparece em qualquer campanha, não só frete grátis. Um desconto de 30% grava o título do mesmo jeito.
  • Campos sem valor não são gravados. Um serviço sem prazo informado pela transportadora não tem cotafrete_previsao_entrega; uma Entrega Local tem só serviço e código, porque não há transportadora nem prazo por trás.

Onde ver na Shopify

Abra o pedido no admin. Os atributos ficam no bloco Informações adicionais (Additional details), na lateral do pedido.

Os atributos são gravados alguns segundos depois do pedido ser criado. Se uma integração puxa o pedido no mesmo instante, pode pegar sem os atributos; a maioria sincroniza em intervalos e não sente isso.

No ERP

O caminho depende do ERP, mas a lógica é a mesma: mapear pelo código do serviço, não pelo nome.

cotafrete_codigo_servico é gerado pelo app e nunca varia pra um mesmo serviço. Os dois campos de nome são textos visíveis, que podem mudar se a transportadora renomear o serviço ou se você customizar o nome no app. Um mapeamento por código continua valendo.

Na API

Os atributos vão junto com o pedido em qualquer leitura:

  • API Admin GraphQL: campo customAttributes do Order (key e value).
  • API REST: array note_attributes do pedido.
  • Webhooks de pedido (orders/create, orders/paid e os demais): o payload traz note_attributes com os mesmos pares.

Serve pra integração própria, planilha, automação (Make, n8n, Zapier) ou pra alimentar o sistema de expedição.

Na página do pedido, pro cliente

Em Liquid, o pedido expõe os atributos em order.attributes. Dá pra usar nos templates de notificação (Configurações → Notificações) e nas páginas de pedido da conta do cliente pra dizer, por exemplo, por qual transportadora o pacote vai e quando deve chegar:

{% if order.attributes.cotafrete_transportadora %}
  <p>
    Seu pedido vai pela <strong>{{ order.attributes.cotafrete_transportadora }}</strong>
    ({{ order.attributes.cotafrete_servico }}).
    {% if order.attributes.cotafrete_previsao_entrega %}
      Previsão de entrega: <strong>{{ order.attributes.cotafrete_previsao_entrega }}</strong>.
    {% endif %}
  </p>
{% endif %}

Nos e-mails de notificação (confirmação de pedido, envio confirmado), o objeto disponível é attributes, sem o order. na frente: {{ attributes.cotafrete_transportadora }}.

Dois cuidados: sempre teste a existência do atributo com {% if %}, porque um pedido de Entrega Local ou um serviço sem prazo não tem todos os campos; e trate a previsão como estimativa no texto, porque é o prazo calculado na cotação, não o rastreio.

Por que o nome do frete não carrega tudo isso

Porque cada nome diferente vira um método de envio novo no ERP. Se a data ou a campanha entrassem no nome do serviço, você teria “SEDEX - 22/07”, “SEDEX - 23/07”, “SEDEX - Black Friday” e assim por diante, e o cadastro do ERP viraria uma lista sem fim.

Por isso o Cota Frete mantém o nome do serviço fixo e joga o que varia pra segunda linha do frete (que o cliente vê no checkout) e pros atributos do pedido (que o ERP, a API e o Liquid leem).

Uma exceção: com o agrupamento de frete ativo, o nome do serviço passa a ser o nome do grupo (“Econômico”), e por trás dele a transportadora muda a cada pedido. O ERP vê sempre “Econômico”; cotafrete_transportadora é o que diz quem está entregando.

Relacionados

Última atualização: agosto de 2026