API Sales

A API Sales (Travellink Api Sales) permite que sistemas externos — backoffices, ERPs, ferramentas de BI, conciliação financeira etc. — consultem as vendas (reservas aéreas, bilhetes, hotéis, carros, taxas de serviço e outros produtos) registradas no ambiente Travellink / Wooba.

💡 Comece por aqui

Antes de implementar, leia a página Uso adequado. Ela descreve o fluxo esperado de toda integração: List → Details (um a um) → Change.

Serviços disponíveis

Serviço	Método	Rota	Para que serve
List	POST	{URL}list	Lista as vendas a partir de critérios de busca (período, tipo, status, locator…). Retorna apenas um resumo de cada transação, incluindo o UniqueId.
Details	POST	{URL}details	Retorna o detalhamento completo de uma transação (pagamentos, tarifas, taxas, passageiros, fornecedor…), a partir do UniqueId.
Change	POST	{URL}change	Altera o status de importação de uma transação. Usado para marcar a venda como já processada pelo seu sistema (ImportState: 2).

Além dos serviços acima, existe a notificação por Webhook, que avisa seu sistema sempre que uma transação sofre uma alteração relevante.

Ambientes

O endpoint de consumo é formado por URL base + nome do serviço (list, details ou change).

Ambiente	URL base
Sandbox	https://wooba-sandbox.travellink.com.br/TravellinkWebApi//api/v1/sales/
Produção	Consultar o consolidador / operadora

Exemplo: https://wooba-sandbox.travellink.com.br/TravellinkWebApi//api/v1/sales/list

⚠️ Credenciais e endpoints de produção

As informações de produção de cada ambiente (Consolidador / Operadora / Agência Wooba) devem ser solicitadas diretamente ao contratante do desenvolvedor. A Wooba não cria nem repassa credenciais ou endpoints gerenciados pelos clientes.

Formato padrão de requisições e respostas

• Todos os serviços usam o método HTTP POST com cabeçalho Content-Type: application/json.
• Toda requisição exige obrigatoriamente os headers de desenvolvedor (developer-token e developer-access-code) e o objeto AccessCredentials no corpo. Veja o passo a passo em Autenticação.
• O servidor sempre retorna código HTTP 200, encapsulando o resultado ou as eventuais falhas na estrutura de resposta padrão (DefaultRS).

Estrutura raiz das respostas

Todas as respostas da API compartilham os mesmos campos base de controle:

Campo	Tipo	Descrição
Request	object	Eco do objeto da requisição enviado pelo cliente. O sub-objeto AccessCredentials é sempre retornado como null por questões de segurança.
OffSet	string	Fuso horário efetivamente aplicado na serialização das datas da resposta (ex.: "-03:00:00").
Transactions	TransactionHeader[]	(Exclusivo do List) Array contendo os cabeçalhos das transações localizadas. Retorna null em caso de erro.
Transaction	TransactionDetail	(Exclusivo do Details e Change) Detalhes da venda no serviço Details (ou null no Change e em caso de erro).
Errors	Error[]	Coleção de erros gerados no processamento. Retorna um array vazio ([]) em operações bem-sucedidas.
Success	boolean	Indicador dinâmico de sucesso. Retorna true se Errors estiver vazio (Errors.Count == 0), ou false se houver 1 ou mais erros registrados.
RequestDate	string (date-time)	Data e hora em formato ISO 8601 do término do processamento no servidor (ex.: "2022-07-15T12:21:18.91099-03:00").

---

Detalhamento do objeto de erro (Error)

Quando uma requisição não pode ser concluída com sucesso (por falha de validação, parâmetros ausentes, período inválido ou falha interna), o campo Success será false e a lista Errors conterá um ou mais objetos do tipo Error:

{
  "Message": "GetList Error: Maximum period exceeded - 7 days",
  "Exception": ""
}

Propriedades de cada item Error:

• Message (string): Mensagem textual descritiva da regra de negócio violada ou exceção capturada (ex.: "Developer unauthorized access", "GetList Error: DateFrom mandatory", "GetList Error: Maximum period exceeded - 7 days").
• Exception (string): Rastreamento de pilha de execução (stack trace) do servidor .NET. Em ambiente de produção, este campo é sempre retornado como string vazia ("") por diretriz de segurança do backend (System.Diagnostics.Debugger.IsAttached ? ex.ToString() : ""), garantindo que detalhes de infraestrutura não sejam expostos.

Exemplo de resposta com sucesso

{
  "Request": {
    "TransactionUniqueId": "AIR-D70B465D-F2BB-4215-BE72-1D6AE5092A87",
    "ImportState": 2,
    "AccessCredentials": null
  },
  "OffSet": "-03:00:00",
  "Transaction": null,
  "Errors": [],
  "Success": true,
  "RequestDate": "2026-10-09T09:15:30.123-03:00"
}

Exemplo de resposta com erro de validação

{
  "Request": {
    "DateFrom": "2026-01-01T00:00:00Z",
    "DateTo": "2026-01-20T00:00:00Z",
    "AccessCredentials": null
  },
  "OffSet": "-03:00:00",
  "Transactions": null,
  "Errors": [
    {
      "Message": "GetList Error: Maximum period exceeded - 7 days",
      "Exception": ""
    }
  ],
  "Success": false,
  "RequestDate": "2026-10-09T09:15:30.456-03:00"
}

🛑 Regra essencial para desenvolvedores

Sempre avalie a propriedade booleana Success antes de processar o conteúdo de Transactions ou Transaction. Se Success for false, capture as mensagens de erro em Errors[i].Message e registre no log da sua aplicação para diagnóstico.