✨ Added​

• POST /sku/template e POST /orders/template e POST /job — documentado o fluxo de envio de arquivo em duas etapas, que já é o usado pelo produto e não existia no contrato: Action=RequestUploadUrl devolve UploadUrl, Key, Method, Headers (obrigatórios no envio), SizeBytes e ExpiresIn; em seguida Action=ConfirmUpload com o Key cria o processamento. O envio direto por multipart/form-data continua válido. Reenviar o mesmo arquivo é idempotente: devolve o IDJob já existente.

• Campos novos de resposta — todos nullable. Já eram retornados pela API; só não estavam no contrato:

  Operação	Campos	Observação
  POST /user/signin/local	ToursSeen · Origin
  GET /user/privilege · GET /user/{iduser}	ToursSeen
  GET /hub/order/claim/{idhuborderclaim}	ClaimAffectsReputation	Não é booleano: 1 não afeta, 2 afeta, 3 não se aplica, 0 o canal não informou, null a consulta falhou
  GET /orders/hub/{idorder} · GET /hub/order/{idintegration}	SalesChannelLogoUrl · IDConsumer · Index
  GET /orders/hub · GET /company/dashboard/order/status	StatusColorCode
  GET /sku/distribution-center	DistributionCenterIDConsumerList · DistributionCenterConsumerList · IDStockKeepingUnitWarehouseBestBeforeDays · WarehouseBestBeforeDaysName
  GET /type/order/payment/{idtypepayment}/rate	AdditionalBusinessDays · AdditionalBusinessDaysPosition · NfTPag · NfTBand · RefundMethod	Em AdditionalBusinessDaysPosition: 1 início, 2 final
  GET /sku/inventory-summary/{idstockkeepingunitinventorysummary}	ItemsCount · HasNextPageItems · InventoryLogs
  GET /sku	QtyReserved · QtyHandling · QtyOnStock · QtyReservedHandling
  GET /sku/movement	IDCategory · AbcCurve · MainImageThumbnailURL · Category · CategoryTree
  GET /fulfillment/packing/picking-list/{idpickinglist}	KitBarCodeList	Dentro de cada item
  GET /fulfillment/picking/basket	IDPickingList	No histórico do cesto
  GET /orders/{idorder}	ExchangeReceiptBase64Encode

• Query params documentados — existiam e eram lidos pelo handler, mas não estavam no contrato:

  Operação	Parâmetro	Para que serve
  GET /orders	LastID	Paginação por cursor
  GET /orders/hub	CreationTimestampFrom · CreationTimestampTo	Recorte por data de criação
  PUT /orders/{idorder}	Resend · TypeMessage	Reenvio de mensagem ao cliente
  GET /accounts/payable	IDTypeCostCenter	Filtro por centro de custo
  GET /sku/batch	IDCompanySalesPolicy	Preço da política informada
  GET /type/order/type	IsTransfer	Só tipos de transferência
  POST /purchase/{idpurchase}/check	CreateNewPurchaseSentMore	Recebimento a mais gera novo recebimento
  POST /sku/pricing/{idsku}	UpdateIfPossible	Atualiza só o que for possível

  Além desses, Page foi documentado em cinco listagens que já paginavam sem dizer.

• Request bodies modelados onde o contrato trazia corpo vazio ou parcial:

  Operação	O que entrou
  POST /orders	Corpo completo, com Items[] e Payments[] detalhados
  POST /consumer · PUT /consumer/{idconsumer}	Cadastro de cliente
  PUT /sku/{idsku}	Cadastro de SKU
  POST /supplier · PUT /supplier/{idsupplier}	Cadastro de fornecedor
  PUT /purchase/{idpurchase} · POST /purchase/{idpurchase}/check	Recebimento e conferência
  POST /sku/pricing/{idsku}	Preços
  POST /user/report	Relatório customizado
  POST /company/sales-policy	Política comercial
  POST /fulfillment/picking	Picking
  POST /hub/warehouse	DE-PARA de armazém
  POST /user/signin/local	Login
  PUT /sku/resupply/{idstockkeepingunitresupplylist}	Ressuprimento
  POST /purchase/feed/invoice-xml	Feed de NF-e

• 400 documentado no envio de anexo do Hub — POST /hub/order/{idintegration}/action/file e POST /hub/order/claim/{idhuborderclaim}/action/file só declaravam 200. Agora trazem as sete mensagens de recusa: arquivo não enviado, arquivo inválido, falha ao salvar, recusa do canal por extensão/tamanho, canal sem recurso de anexo, pedido de integração não localizado e integração não autenticada.

• Enums cruzados com os CSVs canônicos: tipos de devolução (31 valores) e categorias e bandeiras de pagamento; CST e modalidade de ICMS na resposta de POST /tax/{idtaxdepartment}/cfop/{idtax}/interstate e do PUT correspondente; status de pedido em GET /company/dashboard/order/status; tipos de SKU em GET /sku e nas demais listagens; e status de pedido de compra e de reserva no detalhamento de saldo.

🔄 Changed​

• GET /sku/balance e GET /sku/{idsku}/warehouse — mudou o significado de QtyReserved e QtyHandling: pedidos do fluxo de orçamento (50–56) e 23 Em espera etiqueta passaram a contar como reserva, e 97 Reversa finalizada saiu de manuseio. O total (QtyOnStock) não muda — muda a distribuição.
• GET /accounts/receivable/marketplace-conciliation — os campos *Pct são frações de 0 a 1 (0,15 = 15%), não percentuais; e o corte de página é aplicado antes do agrupamento, então uma conciliação pode ficar partida entre duas páginas.
• PUT /hub/product/{idhubproduct} — com SyncVariations=1 a resposta é um objeto (IDHubProduct, TotalUpdates, Results[]), não o anúncio. Falhas individuais não abortam a sincronização.
• GET /type/order/payment — com OrderReturn=1 a lista começa com um item sintético cujo IDTypePayment é o literal ORIGINAL (deixa de ser numérico).
• GET /sku/inventory-summary/{idstockkeepingunitinventorysummary} e correlatos — a lista de Items passou a ser paginada em 5000 registros; use Page e confira HasNextPageItems.
• GET /sku/production/{idstockkeepingunitproduction} — no detalhe da ordem de produção, a lista Items é dos insumos consumidos, não do que foi produzido; as descrições dos campos diziam o contrário. Corrigido um a um. O que a ordem produz está no cabeçalho (IDSku, SkuName, Quantity); Items traz o que saiu do estoque para fabricá-lo, com custo por linha. Vale para as outras sete operações de produção, que devolvem o mesmo detalhe.
• Cerca de 60 operações tiveram a lista de mensagens [BadRequest] criada ou corrigida com o texto literal do handler — inclui ~25 correções de acentuação (esta → está, excluido → excluído, codigo → código) que quebravam tratamento de erro por comparação de texto.

🐛 Fixed​

• DELETE /accounts/receivable/{idaccountreceivable}/payment/{idaccountpayment} — a documentação prometia devolver a conta atualizada; o corpo real vem sempre vazio ([]). A exclusão acontece normalmente — refaça o GET para atualizar a tela. (Defeito de implementação: a recarga usa a chave do lado "a pagar". Reportado ao time.)
• POST /sku/{idsku}/cost/recalculate — o schema do 200 documentava {status, message}, campos que o handler nunca produziu. O corpo real é {Message} com texto fixo.
• POST /sku/template — o schema do 200 documentava o envelope interno da integração em vez do corpo entregue ao cliente (IDJob + Message).
• GET /hub/order/claim/{idhuborderclaim} — os valores de ShippingMethod documentados (carrier, delivered_by_seller) não existem; os reais são mail, entrusted, personal_delivery e email.
• PUT /company — SefazAmbienteNF, SefazAmbienteNFC e SefazAmbienteServiceInvoice estavam marcados como nullable sendo colunas obrigatórias: enviar null faz a gravação falhar.
• 4 descrições de operação que continham texto de instrução em vez do conteúdo (POST /sku/promotion, PUT /sku/promotion/{idstockkeepingunitpromotion}, abertura e fechamento de caixa) foram restauradas.

🧹 Limpeza de contrato​

Itens que a auditoria encontrou documentados sem existir no comportamento real.

• 500 removido de POST /sku/image/{idsku}, PUT /sku/image/{idsku}/{idimage}, DELETE /sku/image/{idsku}/{idimage}, PUT /accounts/receivable/{idaccountreceivable}, GET /fulfillment/picking/basket, PUT /company e DELETE /consumer/{idconsumer}/voucher/{idconsumervoucher} — nenhum desses fluxos produz erro com o prefixo que o gateway mapeia para 500. O 404 de PUT /consumer/{idconsumer} também saiu pelo mesmo motivo.

• POST /sku/image/{idsku} declarava corpo no 404 que a resposta não tem.

• POST /sku/production/{idstockkeepingunitproduction}/finish — o formato declarado do 200 era um array de arrays que a API nunca devolveu. Passou a declarar o detalhe do recebimento, que é o que ela retorna de fato — o mesmo formato de GET /purchase/{idpurchase}.

• POST /sku/distribution-center e PUT /sku/distribution-center/{idstockkeepingunitdistributioncenter}, e o mesmo par em /purchase/schedule — criação e atualização compartilhavam um único formato de corpo, mas as regras diferem: o que é obrigatório ao criar, e o que a omissão de um campo significa ao atualizar (apagar × manter). Agora cada uma declara o seu, e a descrição de cada campo diz o que a omissão faz.

• GET /orders/hub e GET /orders/hub/{idorder} — a listagem e o detalhe do pedido integrado estavam descritos por um formato só, que misturava campos dos dois. Agora cada uma declara o que realmente devolve, com a parte comum compartilhada; e os blocos que eram objetos opacos — SKUs, pagamentos, mensagens e reclamações — passaram a apontar para as descrições que já existiam.

  Divergências corrigidas no caminho: ShippingEstimateHandlingLimitDate era date numa e date-time na outra (vale date-time); OrderId estava nullable sem ser; QuantityItems era integer numa e number na outra; CompanyIntegration vem nas duas, não só no detalhe. Entraram StatusColorCode e o enum de IDStatusInvoice. IDCompany e IntegrationLogoUrl saíram — eram documentados na listagem e nenhuma das duas consultas os devolve; o logotipo existe só no detalhe, com o nome SalesChannelLogoUrl.

  GET /hub/order/{idintegration} devolve exatamente o mesmo que GET /orders/hub/{idorder} — era essa duplicidade que mantinha os dois formatos.

✅ Fechado nesta leva​

Itens que estavam listados como pendentes e foram resolvidos:

• PUT /orders/{idorder}/sku/{idskumovement} não devolve o pedido inteiro: devolve um array de um item, em duas formas conforme a apuração de imposto do pedido. Com imposto manual, vem o item completo com todo o cadastro do SKU na mesma linha (177 campos); nos demais casos, o mesmo formato de POST /orders/{idorder}/sku, agora com IDNfCstIbsCbs. Ambas as formas estão declaradas.
• PUT /orders/{idorder}/payment/{idaccountpayablereceivable} também não devolve o pedido — a rota é atendida pelo mesmo processo de contas a receber, e o corpo é o detalhe do título, igual ao de PUT /accounts/receivable/{idaccountreceivable}.
• Tipos corrigidos: IDModuleFavorite, no cadastro de usuário (GET /user/{iduser} e correlatas), e IDWarehouseHub, no pedido integrado (GET /orders/hub/{idorder}), são string e não integer.
• GET /company/dashboard/external e GET /user/signin/external foram descritos no spec de origem. Eles continuam fora da referência publicada por decisão de escopo (rotas de uso exclusivo do app, na lista de exclusão de prepare-spec) — o registro serve para quem lê o contrato interno.

🐞 Validação que virava erro de servidor — corrigido​

Afetava POST /job, POST /sku/template, POST /orders/template e POST /sku/{idsku}/cost/recalculate, que compartilham a mesma função.

As validações dessas rotas encerravam a execução com erro em vez de devolver uma resposta, e o API Gateway convertia isso em 502 com o corpo genérico {"message": "Internal server error"}. Na prática, quem errava o envio de planilha ou a ação em massa recebia "erro interno" no lugar da mensagem que dizia o que fazer — eram 100 chamadas por semana terminando assim.

Corrigido nesta versão: as quatro rotas passaram a devolver 400 de verdade, com o texto em errorMessage, para todas as validações. O 400 documentado aqui vale integralmente; não há mais caso que escape como 502.

O mesmo defeito existia, numa única ocorrência, no envio de anexo em mensagem do Hub — POST /hub/order/{idintegration}/action/file e POST /hub/order/claim/{idhuborderclaim}/action/file —, na recusa por integração não autenticada. Também corrigido.

A varredura cobriu as 57 rotas de proxy: as 34 atendidas por PHP já respondiam 400 corretamente, e entre as 10 em Node só essas duas funções tinham o problema.

• Nos itens do pedido (GET /orders/{idorder}), o campo ReverseTaxCalculation estava com a condição invertida: o texto dizia que os impostos somam quando o valor é 1, e o comportamento soma quando é 0. Corrigido.

✨ Added​

• GET /user/tag — lista as tags de acesso de usuário das empresas do token (filtro opcional IDAcess).
• GET /user/jobtitle — lista os cargos (organograma) das empresas do token; filtros IDUserJobTitle e AllStatus.
• POST /user/jobtitle — cria um cargo (UserJobTitleName obrigatório; IDUserJobPositionList, IDUserJobTitleUpper opcionais).
• PUT /user/jobtitle/{idjobtitle} — atualiza um cargo (semântica de omissão: IDUserJobTitleUpper vazio desvincula o superior; omitido mantém).
• DELETE /user/jobtitle/{idjobtitle} — remove um cargo.
• O organograma de cargos e funções está no corpo de resposta dessas operações — a listagem traz a hierarquia montada, e a edição aceita o cargo superior.

🔄 Changed​

• Cadastro de Usuários — POST /user, GET/PUT /user/{iduser} e GET /user/menu: corpo e resposta foram ampliados com os dados profissionais (IDUserJobTitle, IDWorkScale, IDUserUpper, IDModuleCurrent e respectivos nomes, mais IDUserJobPositionCurrent); GET /user ganhou os filtros Tag e IDModule; PUT /user/{iduser} reconhece o modo DashboardConfig (resposta Dashboard salvo).
• Templates de tracking — GET/POST /carrier/tracking-template e PUT /carrier/tracking-template/{idcarriertrackingtemplate}: corpo e resposta ampliados com IDTypeEventTracking, DaysAfterDelivery e os campos WhatsAppTemplate*; o GET documenta o modo Type=WhatsAppTemplate (retorna um único template do provedor).
• PUT /sku/resupply/{idstockkeepingunitresupplylist}: novo parâmetro de query Draft=1 (salva rascunho, resposta "sucesso") e enum IDTypeResupplyMode (1 Individual / 2 Agrupado / 3 Indireto) adicionado ao body — que antes não tinha enum.
• POST /sku: o corpo ganhou o campo BestBeforeRequired (1 exige informar a data de validade nas movimentações do SKU).
• POST /consumer/{idconsumer}/address: o corpo ganhou o campo ConsumerEmail.
• GET /orders/tracking/{idorder}, GET /fulfillment/packing/picking-list/{idpickinglist} (campos de KIT nos itens) e GET /tax/{idtaxdepartment}: campos de resposta novos/ajustados.
• GET /orders, GET /cte, POST /fulfillment/picking e GET /store-front/cashier/{idbankaccount}: descrição revisada para detalhar melhor o comportamento — sem novos parâmetros nem campos (contrato inalterado). No GET /cte, o parâmetro IDStatusShippingAuctionDif, o modo FreightConciliation=1 e o schema de resposta já existiam.
• POST /type/order/type e PUT /type/order/type/{idordertype}: descrições e contrato ajustados.

🐛 Fixed​

• GET/POST /carrier/tracking-template e PUT /carrier/tracking-template/{idcarriertrackingtemplate}: rótulo do gatilho IDTypeEventTracking = 4 corrigido de "Pagamento aprovado" para "Pedido pronto para manuseio", e removida a menção incorreta a "pesquisa" no evento 3 (Pós-entrega) — conferido em TrackingTemplateModal.jsx.
• GET /user: descrição de IDCompanyInvoice estava invertida — o parâmetro filtra a listagem de usuários por empresa faturadora, não a apuração de comissão. Corrigida.
• PUT /user/{iduser}: removido jargão de tabela de log da descrição (histórico de alteração descrito em linguagem de contrato).
• PUT /user/jobtitle/{idjobtitle}: descrição de IDUserJobPositionList corrigida para avisar que omitir/enviar vazio remove todas as funções vinculadas (evita perda de dados silenciosa).

✨ Added​

• GET /orders — novo query param LastID: paginação por cursor/keyset. Quando informado, ignora o deslocamento de Page e retorna os 2000 pedidos seguintes com IDOrder maior (ou menor, se OrderBy=DESC) que o valor — para percorrer grandes volumes de forma incremental.
• GET /orders/hub — novos filtros CreationTimestampFrom e CreationTimestampTo (data de criação do pedido no canal de origem, distinta de DateFrom/DateTo, que filtram a data de registro do staging).
• PUT /orders/{idorder} — query params Resend e TypeMessage documentados (reenvio de mensagem/notificação do pedido).
• POST /fulfillment/picking — novos parâmetros OriginalPickingListPriority, IgnorePickingPreferenceByAllowResupplyLocation e PreferLocationMoreQuantity (controle de prioridade e de preferência de endereço na geração da picking-list).
• GET /fulfillment/picking/picking-list, GET /carrier/quotation/error, GET /carrier/quotation/rule, GET /accounts/receivable/marketplace-conciliation e GET /carrier/tracking-template — parâmetro de paginação Page documentado.
• GET /consumer/{idconsumer} — query param IDCompanyInvoice.
• GET /sku/batch — novo filtro IDCompanySalesPolicy.
• GET /accounts/payable — novo filtro IDTypeCostCenter (centro de custo).
• GET /invoice/danfe65 — query param InvoiceType.
• GET /type/order/type — query param IsTransfer (1 filtra tipos de pedido de transferência).
• GET /store-front/payment — query param DateFrom.
• POST /purchase/{idpurchase}/receipt — query param CreateNewPurchaseSentMore (gera novo pedido de compra para o excedente recebido a mais).
• POST /sku/pricing/{idsku} — query param UpdateIfPossible.
• GET /hub/resource/auth — parâmetros de callback de autorização documentados: IDTypeCompanyIntegration, shop_id, main_account_id, selling_partner_id, spapi_oauth_code, api_address, url, tempToken, token, shop.
• Request bodies modelados (antes vazios/parciais):
  • POST /orders — corpo completo com os arrays Items[] e Payments[] detalhados, além do campo novo ShippingEstimateHandlingLimitDate.
  • POST /consumer e PUT /consumer/{idconsumer} — cadastro/edição de cliente.
  • POST /sku — corpo atualizado, incluindo Composing.
  • POST /purchase/{idpurchase}/receipt — corpo do recebimento.
  • POST /supplier e PUT /supplier/{idsupplier} — cadastro e edição de fornecedor, com o campo novo.
  • POST /sku/pricing/{idsku} — corpo de preço.
  • POST /user/report — corpo do relatório customizado.
  • PUT /company/sales-policy/{idcompanysalespolicy} — corpo da política comercial.
  • PUT /fulfillment/picking/basket/{idpickinglisbasket} e PUT /fulfillment/picking/picking-list/{idpickinglist} — corpos do cesto e da picking-list.

🔄 Changed​

• POST /orders — documentadas mensagens 400 adicionais emitidas pelo worker: limite de desconto por item excedido, empresa sem armazém padrão, armazém do item fora do CD do pedido, banco/tipo de pagamento não cadastrado.
• PUT /orders/{idorder} — nova validação 400 quando Resend=1 sem TypeMessage.
• POST /purchase/{idpurchase}/receipt, POST /sku, GET /sku, GET /sku/batch, GET /sku/movement, DELETE /sku/batch/{idsku}/{idbatch}, GET /accounts/payable, POST /accounts/payable/{idaccountpayable}/file, GET /invoice/danfe, GET /invoice/danfe65, POST /consumer/{idconsumer}/voucher, POST /company/bill/{idcompanybilling}/report, POST /fulfillment/packing/picking-list/{idpickinglist}/merge, POST/PUT de picking e PUT /company/sales-policy/{idcompanysalespolicy} — descrições revisadas para refletir as regras de negócio atuais (bloqueios, validações e comportamento dos handlers).

✨ Added​

• POST /accounts/bank-account e PUT /accounts/bank-account/{idbankaccount} — novo campo IDCompanyIntegrationPix no request body (integração de Pix vinculada à conta, independente da integração TEF). O PUT passa a documentar também InitialBalance e InitialBalanceDate (modo de ajuste de saldo inicial).
• GET /orders/hub — 24 parâmetros de query agora documentados: ConsumerNameCorporateName, ConsumerCpfCnpj, ConsumerEmail, Order, OrderFrom, IDStatusOrder, IDSalesChannel, ShippingId, PackId, DateFrom, DateTo, IDCompanyIntegration, IDTypeCompanyIntegration, IDIntegration, Coupon, UtmCampaign, UtmMedium, UtmSource, UtmiCampaign, UtmiPage, UtmiPart, OrdersNotCreated, Search, Page.
• GET /purchase — 11 filtros novos, incluindo StockKeepingUnitPurchaseScheduleStatus (1 Recebido, 2 Agendado, 3 Atrasado, 4 Não agendado), IDOrder, chNFeFrom, NfeNumberFrom, StartTimeFrom/StartTimeTo e SinceRecordTimestamp. Cada item da lista ganhou IDStockKeepingUnitPurchaseSchedule.
• GET /sku/movement — novo modo Type=KardexBatch (Kardex por lote, exige IDBatch), cujo item traz saldo e custo acumulados por lote; novo filtro de query IDBatch.
• POST /hub/resource/{idtypecompanyintegration} — parâmetros de query IDOrdersCarrierCollectionList, LabelFormat e token documentados.
• POST /purchase/feed/{idnfevents}/manifest — request body documentado: Event (210200 Confirmação, 210210 Ciência, 210220 Desconhecimento, 210240 Operação não Realizada) e Comments (mínimo 15 caracteres para o evento 210240).
• Campos de resposta novos, por operação: IDCompanyIntegrationPix e CompanyIntegrationPix em GET /accounts/bank-account; StatusColorCode (cor do status do pedido por empresa) em GET /fulfillment/packing/collection-list/{idorderscarriercollectionlist}, GET /fulfillment/packing/picking-list/{idpickinglist}, GET /fulfillment/picking/picking-list/{idpickinglist} e GET /hub/carrier; e WarehouseName, Status, TypeOrder, StatusOrder e StatusColorCode em GET /hub/warehouse.

🔄 Changed​

• Enums revisados contra a base: IDStatusPurchase (0–12) em GET /purchase; categorias de pagamento TEF (22 Crédito, 23 Débito, 24 Pix) em POST /store-front/cashier/{idbankaccount}/payment.
• 400 de POST /accounts/bank-account e do PUT correspondente passa a listar a mensagem Integração Pix não existe.
• Descrições de operação atualizadas em GET /orders/hub (busca textual e modo OrdersNotCreated), GET /sku/movement (modos de Type) e POST /purchase/feed/{idnfevents}/manifest.

🐛 Fixed​

• Removido o parâmetro de query inexistente IDCompany de GET /orders/package (o handler não o lê).

O que está disponível nesta versão​

Cobertura da API​

• 772 endpoints documentados a partir do spec OpenAPI 3.0 do idworks
• 126 schemas de request/response com tipos, campos obrigatórios e exemplos
• 28 categorias com sub-agrupamento automático por recurso (ex: Accounts ▸ Payable, Sku ▸ Production, Hub ▸ Product)

Autenticação integrada​

• Formulário de login na introdução com AccountName + e-mail + senha
• Token JWT obtido via POST /user/signin/local e aplicado automaticamente em todos os endpoints — sem precisar copiar e colar
• Sessão em memória da aba (não persiste após fechar)
• Botão "Login" no canto superior direito para trocar de conta sem voltar para a introdução

Try-it (Send API Request)​

• Painel à direita de cada endpoint para enviar requests reais
• Code samples em cURL, JavaScript, Python, PHP, Go, Ruby, Java e C#
• URL base por conta (https://{AccountName}.api-idworks.com.br/1.0/) com variável editável
• Botão Edit para trocar a conta diretamente sem refazer o login

Navegação​

• Busca tipo "Jump to..." com atalho ⌘K / Ctrl+K indexando 100% do conteúdo
• Sidebar hierárquica com auto-collapse — só a categoria atual fica aberta
• Seção Models separada no fim com todos os schemas reutilizáveis
• Tema claro/escuro respeitando prefers-color-scheme

Limites da API​

• 5 requisições/segundo por endpoint por conta — exceder retorna 429 Too Many Requests com o header Retry-After

Próximos passos planejados​

• Quickstart com fluxo "do zero ao primeiro pedido"
• Tutorial de webhooks e eventos
• Exemplos prontos por linguagem (snippets reais, não só schemas)
• Documentação de paginação e idempotência

Encontrou algo errado? Tem sugestão? Manda pra dev@idworks.com.br.