Pular para o conteúdo principal

16/10/2026 — Links de arquivo sem o token embutido

Os links para baixar arquivos que a API devolve nas respostas (XML e DANFE de notas, etiquetas, anexos de contas, templates) deixam de carregar o token do usuário dentro da URL. Quem baixa passa a enviar o header Authorization: Bearer <token> no GET do link. Se a sua integração guarda esses links e os abre sem header, ajuste antes que a rota seja publicada: enviar o header já funciona hoje.

⚠️ Breaking​

  • Abrir o link da resposta sem enviar o header deixa de funcionar. Hoje o link se basta porque o JWT de quem consultou vai dentro da URL (&token=…). Sem ele, o GET no link volta 401. Exemplo, no feed de NF-e:

    Antes:  https://{AccountName}.api-idworks.com.br/1.0/invoice/danfe?Folder=Inbound&Type=XML&Origin=Feed&token=<token>&File=<chave-acesso>
    Depois: https://{AccountName}.api-idworks.com.br/1.0/invoice/danfe?Folder=Inbound&Type=XML&Origin=Feed&File=<chave-acesso>
            + header  Authorization: Bearer <token>

    Os campos afetados e como baixar cada um:

    OperaçãoCampos com linkComo baixar
    GET /purchase/{idpurchase}UrlFileXml · UrlFileDanfe · Payments[].Files[].FileUrlLink + header Authorization
    GET /purchase/feed · PUT /purchase/feed/{idnfevents} · POST /purchase/feed/{idnfevents}/manifestXmlFile · XmlDanfeLink + header Authorization
    GET /invoice-service/{idserviceorder}UrlFileXml · UrlFileDanfeLink + header Authorization
    GET /invoice-service/feedXmlFile · XmlDanfeLink + header Authorization
    GET /cteXmlFile · XmlDanfeLink + header Authorization
    GET /accounts/payable/{idaccountpayable} · GET /accounts/receivable/{idaccountreceivable}Files[].FileUrlLink + header Authorization
    PUT /orders/{idorder}/invoice/{nfenumber}UrlFileXml · UrlFileDanfeLink + header Authorization
    GET /type/job/typeTemplateUrl (quando o template é servido pela API; URL externa https:// segue como cadastrada)Link + header Authorization

  • Use o link exatamente como veio (inclusive o ?View=1&File= que termina os links de anexo) e anexe o header; não monte a URL concatenando &token=. O token vale o tempo configurado no login (14 horas por padrão), então use o vigente na hora de baixar, e não o que estava na época da consulta.

  • O parâmetro token na URL continua aceito pelas rotas de download, mas evite: a query string fica em log, histórico do navegador e cabeçalho Referer.

✨ Added​

  • GET /orders/{idorder} — novo parâmetro de query UrlToken. O comportamento padrão não muda: os links de etiqueta e de nota (Packages[].UrlLabel, Packages[].UrlLabelDownload, Files[].UrlFileXml, Files[].UrlFileDanfe e Files[].UrlFileDanfeSimplificado) continuam com o token de quem consultou e abrem direto, para não quebrar integrações que baixam por eles. Com ?UrlToken=0 os links saem sem o token e quem baixa envia o header Authorization.

🔄 Changed​

  • GET /supplier/{idsupplier} — em CarrierTableUpload[], o campo UrlFile deixa de ser um link da API com o token e passa a ser uma URL pré-assinada do S3, válida por 2 horas. Abra o link direto, sem o header Authorization. Vem null quando a linha não tem arquivo ou o link não pôde ser gerado; consulte o fornecedor de novo para receber um link novo depois que ele expirar.
  • GET /cte/invoice-xml e GET /invoice-service/{idserviceorder}/invoice/invoice-xml — o parâmetro token deixa de ser obrigatório no contrato: o header Authorization sempre bastou. Nas rotas GET /invoice-service/feed/invoice-xml e GET /accounts/payable/{idaccountpayable}/file/{idfile} a descrição do token foi atualizada no mesmo sentido.
  • Os textos que chamavam esses links de "URL assinada" ou "pré-assinada" foram corrigidos em GET /purchase/{idpurchase}, GET /purchase/feed, GET /invoice-service/feed, GET /invoice-service/{idserviceorder} e GET /cte: só o UrlFile de GET /supplier/{idsupplier} é, de fato, pré-assinado.

🔒 Security​

  • O JWT deixa de viajar dentro de URLs devolvidas pela API. Em URL, o token aparece em log de proxy, histórico do navegador e Referer; nas listas, uma página de 500 notas repetia o mesmo token 1.000 vezes na resposta; e nas rotas com cache, o token de quem consultou primeiro podia ser entregue a outros usuários da mesma conta.

Como migrar​

  1. Em todo GET de link vindo de uma resposta, envie Authorization: Bearer <token>. Pode fazer isso já: o header é aceito hoje e continua depois da mudança.
  2. Se você guarda o link para baixar depois, guarde o link e gere a chamada com o token vigente. No UrlFile do fornecedor, o link expira em 2 horas: reconsulte em vez de reaproveitar.
  3. Se precisar manter links que abrem sozinhos em GET /orders/{idorder}, não mude nada: o padrão continua com o token.

Veja também Baixar arquivos pelos links da resposta.