Respostas de erro comuns
Os serviços da nossa API compartilham os formatos comuns de respostas, mensagens e códigos de erro a seguir.
Recomendações de tratamento de erros da Rapid
Lógica de tratamento de erros
- As plataformas e os parceiros devem garantir que a lógica de tratamento de erros esteja implementada para lidar com erros nas APIs de Compras e Reservas.
- Sempre use um
affiliate_reference_idexclusivo para cada solicitação de reserva, a menos que especificado nas observações a seguir. - Você deve revisar e atualizar constantemente sua lógica de tratamento de erros, especialmente para solicitações de reserva.
- Todas as respostas Rapid API possuem um código HTTP correspondente; veja abaixo a lista de códigos HTTP de resposta.
Tempo limite de conexão ou de comunicação
Para solicitações de reserva de voos, recomenda-se um tempo limite de conexão de API de 120 segundos; para hospedagem e nossas outras APIs, recomendamos 90 segundos. No entanto, você pode optar por usar um tempo limite de conexão menor para chamadas de disponibilidade de compras.
Se você não receber uma resposta em 120 segundos, Rapid API emitirá um erro 5xx porque os tempos limite de conexão do próprio Rapid API estão definidos para 120 segundos.
Em alguns casos, Rapid API não suporta o processo HTTP Expect: 100-Continue. Você pode encontrar problemas de conexão ao tentar conectar-se a servidores com o processo, especialmente no cURL, C#/.NET e algumas outras linguagens de programação que seguem o processo por padrão.
Observação: o gateway HTTP 504 atingir o tempo limite não significa que a Rapid também o atingiu. Nesses casos, ou um serviço de infraestrutura falhou ou o Rapid está atuando como um gateway para outro serviço subsequente e define um limite de tempo limite para esse serviço. Esse tempo limite subsequente será acionado como um erro 504. Se o erro 504 ocorrer em uma chamada de reserva, verifique se a reserva foi criada usando a Recuperação de Itinerário (affiliate_reference_id+ e-mail), pois o problema subsequente pode ter ocorrido antes da criação da reserva (comunicação com o hotel, servidor de pagamento) ou depois (Expedia Group gestão financeira). Verifique também se a conexão com a internet está estável. Um comando Traceroute pode ajudar a identificar problemas de conectividade.
Tratamento de erros 5xx de reserva e recuperação
Um erro de reserva (status 5xx) ou um tempo limite excedido não significa necessariamente que a reserva em si seja inválida. Como o erro pode ter ocorrido após a criação da reserva, Recomendamos que você solicite uma Recuperação de Itinerário com affiliate_reference_id+ e-mail para verificar o status da reserva.
Erros retornados em 90 segundos não indicam o status final da reserva. Normalmente, a maioria das reservas é confirmada em 13 a 30 segundos, embora algumas possam levar até 5 minutos.
Você pode implementar uma lógica para verificar o status da reserva 3 vezes em um período de 90 segundos. A maioria das respostas será confirmada nos primeiros 30 segundos e, em seguida, você poderá confirmar a resposta sem precisar esperar os 90 segundos completos. Caso não tenha recebido uma resposta final, você pode tentar recuperar o item novamente por 30 minutos antes de entrar em contato com os agentes do call center Rapid API para obter suporte adicional.
Use uma chamada à API Retrieve para obter os resultados da reserva (resposta HTTP 200 ou HTTP 404).
A resposta de recuperação retorna informações sobre espera e retomada
Ocasionalmente, após uma reserva de hospedagem bem-sucedida, a resposta da solicitação de itinerário retornará dados que parecem ser de uma reserva em espera/retomada. Assim, em vez das informações de reserva esperadas (quartos, penalidades de cancelamento, etc.), a resposta conterá apenas os tokens necessários para uma situação de espera/retomada.
O motivo é que a reserva, embora válida, ainda está sinalizada como pendente. que vai acabar desaparecendo em alguns minutos. Portanto, as solicitações Itinerary Retrieve precisam ser repetidas até que a reserva seja concluída.
Resposta de exemplo:
{
"itinerary_id": "2667552437552",
"links": [
{
"rel": "retrieve",
"method": "GET",
"href": "/v3/itinerary/{itinerary_id}?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
},
{
"rel": "resume",
"method": "PUT",
"href": "/v3/itinerary/{itinerary_id}?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
},
{
"rel": "cancel",
"method": "DELETE",
"href": "/v3/itinerary/{itinerary_id}?token=MY5S3j36cOcLfLBZjPYQ1abhfc8CqmjmFVzkk7euvWaunE57LLeDgaxm516m"
}
]
}Explicação sobre os erros com estrutura de vários níveis
A resposta da API pode decompor um erro em vários níveis quando um erro single-level não consegue explicar todos os detalhes necessários. A análise das informações em todos os níveis ajudará a esclarecer e solucionar o erro.
Resposta de exemplo:
{
"type": "invalid_input",
"message": "An invalid request was sent in, please check the nested errors for details.",
"errors": [
{
"type": "duplicate_itinerary",
"message": "An itinerary already exists with this affiliate reference id.",
"fields": [
{
"name": "affiliate_reference_id",
"type": "body",
"value": "XXXXXX"
}
]
}
]
}Códigos de resposta HTTP
400 - Bad Request
Retorna caso a sua solicitação esteja corrompida ou tenha valores impróprios.
O código de erro 400 Bad Request indica um problema com o cabeçalho Request Booking. A resposta de erro incluirá o campo de erro inválido real no cabeçalho da solicitação de reserva. O cabeçalho consiste em uma série de arrays e sub-arrays, como salas e pagamentos. A matriz geral é o corpo. Assim, body.email indica o parâmetro de e-mail para o corpo do cabeçalho.
Nota: Para a API de Hospedagem, o array de quartos do cabeçalho de Reserva deve ter o mesmo número de entradas que os quartos solicitados na chamada de Disponibilidade.
Um erro 400 Bad Request denominado Tomcat Exception Report é retornado quando os parâmetros da solicitação são excessivamente grandes, geralmente nas APIs de conteúdo de propriedade e disponibilidade. Para evitar esse erro, reduza o número de propriedades ou remova parâmetros desnecessários da solicitação.
Respostas de exemplo:
Idiomas sem suporte:
{
"type": "invalid_input",
"message": "An invalid request was sent in, please check the nested errors for details.",
"errors": [
{
"type": "language.not_supported",
"message": "Language is not supported. Supported languages are: [de-DE, en-US, es-ES, es-MX, fr-FR, id-ID, it-IT, ja-JP, ko-KR, pt-BR, zh-CN]",
"fields": [
{
"name": "language",
"type": "querystring",
"value": "xx-XX"
}
]
},
{
"type": "filter.mismatch",
"message": "Existing booking is expedia_collect, this cannot be changed",
"fields": [
{
"name": "filter",
"type": "querystring",
"value": "property_collect"
}
]
}
]
}Valor ausente da versão:
{
"type": "version.required",
"message": "You have not specified a version, the supported versions are: [1, 2]",
"fields": [
{
"name": "version",
"type": "path",
"value": "missing"
}
]
}Valor inválido da versão:
{
"type": "version.unsupported",
"message": "You have requested a version that is not supported, supported versions are: [1, 2]",
"fields": [
{
"name": "version",
"type": "path",
"value": "3"
}
]
}401 - Unauthorized
Retorna verdadeiro se o cabeçalho de autorização HTTP estiver ausente ou não puder ser analisado. Cada solicitação para qualquer API Rapid Lodging deve incluir o hash SHA-512 sem salt da concatenação de sua chave de API + segredo compartilhado + timestamp UNIX em segundos.**** Consulte a nossa página de autorização de assinatura para detalhes completos.
Exemplo de resposta 401 não autorizada da API de hospedagem:
{
"type": "request_unauthenticated",
"message": "Data required to authenticate your request is missing. Ensure that your request follows the guidelines in our documentation.",
"fields": [
{
"name": "apikey",
"type": "header",
"value": "jaj3982k239dka328e"
},
{
"name": "signature",
"type": "header",
"value": "129d75332614a5bdbe0c7eb540e95a65f9d85a5b53dabb38d19b37fad6312a2bd25c12ee5a82831d55112087e1b"
},
{
"name": "timestamp",
"type": "header",
"value": 198284729
},
{
"name": "servertimestamp",
"type": "server",
"value": 198284729
}
]
}Para chamadas à API Rapid Flight, você deve incluir um token web JSON (JWT) principal EGToken válido no cabeçalho da solicitação.
Authorization: EGToken principal-JWT={encodedJwt}O JWT principal é obtido por meio da troca de credenciais e tokens do cliente OAuth 2.0; consulte os guias de uso de autenticação OAuth 2.0 e da API de reserva rápida de voos para obter detalhes.
403 - Forbidden
Retorna quando o seu cabeçalho de autorização HTTP é válido, mas você não tem permissão para acessar o recurso solicitado.
Exemplo de resposta 403 Forbidden:
{
"type": "request_unauthorized",
"message": "Your request could not be authorized."
}404 - Not found
Retorna se o recurso solicitado da API não pode ser encontrado. Verifique o URL da sua solicitação em relação aos nossos exemplos documentados.
A API de Geografia de Hospedagem</a> e a API de Conteúdo</a> também usam respostas 404 para indicar quando os arquivos ou recursos de geografia ou content-specific solicitados não podem ser localizados. Consulte os exemplos completos nas respectivas páginas de documentação.
O código 404 após uma recuperação de itinerário indica que a reserva não foi encontrada. Se a solicitação de recuperação foi usada devido a um erro de reserva, isso indica que a reserva não foi criada. No entanto, você precisa garantir que os parâmetros da solicitação da API de recuperação de itinerário sejam válidos, portanto, certifique-se de que o campo de recuperação affiliate_reference_id, o e-mail e/ou o número do itinerário estejam corretos. Além disso, se a chamada da API Retrieve foi feita em menos de 90 segundos após a chamada da Booking, recomendamos que você tente recuperar os dados novamente.
Resposta de exemplo:
{
"type": "resource.not_found",
"message": "The requested resource could not be found."
}409 - Price mismatch
Muitos fornecedores usam preços dinâmicos, ou o que também é chamado de "preços time-based". Isso significa que os preços variam de acordo com os algoritmos de oferta e demanda. Expedia Group recebe taxas atualizadas várias vezes por segundo, o que significa que as taxas mudam com frequência.
É importante observar que esta é normalmente a escolha do provedor em vez de Expedia Group. Além disso, como há armazenamento em cache em vários níveis para tarifas e disponibilidade, pode haver diversas camadas de latência em qualquer reserva.
A discrepância de preços (PMM, na sigla em inglês) é uma situação esperada e pode ocorrer por diversos motivos, incluindo a degradação dos sistemas ou sistemas que não refletem preços atualizados. Você deve monitorar a frequência desses eventos e entrar em contato com o Suporte caso a taxa aumente repentinamente ou atinja um limite predefinido.
Se um PMM (Perfil de Modificação de Modificação) ocorrer para vários resultados ao mesmo tempo, você deve verificar se há uma possível degradação rápida.
Se um PMM (Payment Matching) apresentar os mesmos resultados por um longo período, provavelmente isso se deve ao carregamento incorreto de tarifas pelo provedor. Você pode entrar em contato com o Suporte Técnico para verificar.
Para se recuperar de um erro de preço (PMM), faça novamente a chamada de Verificação de Preço (API de Hospedagem) ou Detalhes do Voo (API de Voos) para obter um novo token de URL de reserva. É possível usar o mesmo affiliate_reference_id na chamada de reserva.
Resposta de exemplo:
{
"type": "price_mismatch",
"message": "Payment amount did not match current price, please check price and try again.",
"fields": [
{
"name": "payments.amount",
"type": "body",
"value": "100.00"
},
{
"name": "price.amount",
"type": "body",
"value": "120.00"
}
]
}410 - Gone or sold out
Retorna se o link Rapid API que estava sendo seguido expirou ou se o item solicitado não está mais disponível no estoque.
Muitos fornecedores têm ligações de comunicação diretas e síncronas com Expedia Group que ocorrem em tempo real.
A reserva por comunicação síncrona ocorre quando são feitas chamadas de verificação de disponibilidade e preço (API de hospedagem) ou de detalhes de voo (API de voos) com base nos dados do provedor fornecidos, que gerenciamos. Esse erro ocorre quando não há estoque suficiente para a reserva selecionada.
Essa situação pode ser temporária e uma nova tentativa poderá encontrar o estoque disponível. Aguarde 90 segundos e verifique o status com uma solicitação de recuperação usando o mesmo affiliate_reference_id que foi enviado com a reserva. Caso não seja encontrada nenhuma reserva, o viajante poderá ter que escolher outra opção.
As mensagens de erro de produto esgotado também podem ocorrer se a conexão com o provedor estiver degradada. Nesse caso, não temos indicação da disponibilidade real.
Resposta de exemplo:
Link expirado:
{
"type": "link.expired",
"message": "The link you followed has expired. Please request a new link."
}Esgotado:
"type": "rooms_unavailable",
"message": "One or more requested rooms are unavailable."426 - Upgrade required
Retorna verdadeiro se a solicitação não utilizou Transport Layer Security (TLS), um protocolo criptográfico que substitui o Secure Sockets Layer (SSL).
Resposta de exemplo:
{
"type": "upgrade_required",
"message": "This service requires the use of TLS."
}429 - Rate limit error
O código de status 429 é retornado quando o número de solicitações excede um limite. Cada solicitação está sujeita a dois limites diferentes: aqueles em que uma integração está enviando solicitações em uma taxa acima do limite e aqueles em que os servidores do Expedia Group estão com uma carga acima do limite.
Ao fazer uma solicitação à API Expedia Group, o servidor receptor verifica se o número de solicitações está dentro do limite. Se estiver, o processo vai continuar, e a contagem vai aumentar para o cliente. Se a contagem de solicitações feitas por um cliente exceder o limite, o servidor vai retornar uma resposta com um código de status HTTP 429 (too many requests).
O servidor pode, como outra opção, incluir um cabeçalho Rate-Limit-Day-Reset e Rate-Limit-Minute-Reset. Isso indica quanto tempo você precisa esperar antes de enviar a próxima solicitação. São as informações de data/hora de quando a próxima queda vai ocorrer, em microssegundos (não milissegundos).
Por exemplo, quando convertido em data/hora, o valor "15489792000000" resulta em Friday, February 1, 2019 12:00:00 AM (UTC).
Observação: se você receber um erro por muitas solicitações, aguarde pelo menos cinco minutos antes de tentar uma solicitação corrigida. Tentar de novo com mais frequência vai causar falhas repetidas devido ao tempo do cache.
Resposta de exemplo:
HTTP/1.1 429 Too Many Requests
Connection →keep-alive
Content-Length →106
Date →Fri, 01 Feb 2019 06:20:51 GMT
Rate-Limit-Day-Remaining →18
Rate-Limit-Day-Reset →1548979200000
Rate-Limit-Minute-Remaining →0
Rate-Limit-Minute-Reset →1549002000000
Rate-Limit-Reduction-Status →inactive
Server →EAN
Transaction-Id →003224d2-1407-42fe-8bf8-6d74226e7f00500 - Internal server error
Retorna um erro dentro do Rapid API ou em sistemas upstream. Siga as instruções no campo de mensagem se uma ação específica for apresentada. Caso contrário, tente a sua solicitação de novo com o mesmo affiliate_reference_id.
Rapid API responde com HTTP 500 quando detecta um problema, mas não consegue especificar qual é o problema exato. Todos os parceiros devem esperar algumas respostas de código 500 em seu uso do Rapid API de tempos em tempos.
Um erro HTTP 500 também pode ocorrer quando um ponto de venda incompatível é usado, como a Síria.
Se você recebeu o erro em uma resposta da API que não seja de criação de reserva ou cancelamento de reserva e não souber de alguma degradação, repita a solicitação mais tarde. A resposta pode incluir um cabeçalho Retry-After para indicar um intervalo mínimo, em segundos, antes de uma nova tentativa.
Se você recebeu o erro na resposta da API ao criar uma reserva:
- Aguarde 90 segundos e verifique o status com uma solicitação de recuperação usando o mesmo
affiliate_reference_idque foi enviado com a reserva. - Se nenhuma reserva for encontrada ou se você continuar recebendo o erro 500, tente fazer a reserva novamente mais tarde.
Se você recebeu um erro na resposta da API ao cancelar uma reserva:
- Aguarde 90 segundos e verifique o status com uma solicitação da Itinerary Retrieve usando o
itinerary_idconhecido. - Se a reserva não for cancelada ou se você continuar recebendo o erro 500, tente novamente o pedido de cancelamento mais tarde.
Respostas de exemplo:
{
"type": "unknown_internal_error",
"message": "An internal server error has occurred."
}{
"type": "internal_error",
"message": "An internal server error has occurred. Please discard any previously received results in this pagination and restart the pagination from the beginning."
}503 - Service unavailable
O erro HTTP 503 geralmente é temporário e indica que Rapid API, ou um serviço subsequente, está atualmente impossibilitado de processar a solicitação. Existem várias razões possíveis para isso, desde uma sobrecarga temporária até a perda de conexão com o provedor.
Se você recebeu o erro em uma resposta da API diferente de Criar Reserva ou Cancelar Reserva, e não há nenhuma degradação conhecida, tente novamente sua solicitação mais tarde. A resposta pode incluir um cabeçalho Retry-After para indicar um intervalo mínimo, em segundos, antes de uma nova tentativa.
Se você recebeu o erro na resposta da API ao criar uma reserva:
- O link de reserva da sua resposta anterior de Verificação de Preço (API de Hospedagem) ou Detalhes do Voo (API de Voo) expira após um curto período. Se você recebeu um código de erro HTTP 503 após a sua primeira tentativa, é provável que o link tenha expirado. Use um novo link e tente reservar outra vez.
- Se você receber um erro 503 na segunda tentativa, aguarde 90 segundos e verifique o status com uma solicitação de recuperação usando o mesmo
affiliate_reference_idque foi enviado com a reserva. - Caso nenhuma reserva seja encontrada ou você continue recebendo o erro 503, tente fazer a reserva novamente mais tarde.
Se você recebeu um erro na resposta da API ao cancelar uma reserva:
- Aguarde 90 segundos e verifique o status com uma solicitação da Itinerary Retrieve usando o
itinerary_idconhecido. - Se a reserva não for cancelada ou se você continuar recebendo o erro 503, tente novamente o pedido de cancelamento mais tarde.
Resposta de exemplo:
{
"type": "service_unavailable",
"message": "This service is currently unavailable."
}504 - Gateway time out
O erro HTTP 504 geralmente não se origina no Rapid API, mas sim na infraestrutura de nuvem ou de borda, e indica que um componente da infraestrutura de rede (como o balanceador de carga) falhou durante a transação. Geralmente é um evento temporário.
Nota: Pode ocorrer um tempo limite antes ou depois da criação do itinerário, portanto, sempre verifique se o itinerário foi criado.
As respostas de erro HTTP 504 (e 502) estão em formato HTML, em vez do par objeto tipo JSON/mensagem do Rapid API. Isso é mais um indício de que esses erros não são gerados por Rapid API.
Resposta de exemplo:
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
</body>
</html>Taxa-limite de respostas de erro
Para estabelecer seus próprios valores de limite, você deve medir a taxa diária dos seguintes códigos de resposta: 409, 410, 500, 503 e 504. Caso o limite seja ultrapassado, entre em contato com o suporte do Rapid API.
Expedia Group não possui valores de limite definidos, pois eles variam dependendo do mercado da sua organização, bem como de outros fatores. O conhecimento do mercado é essencial para determinar por que ocorrem algumas respostas errôneas. Nossa previsão é de que até 5 a 6% das chamadas de reserva falhem com o código de erro 50x em um período diário ou semanal.
Com o tempo, você deverá ser capaz de calcular seus próprios valores limite. Não procure apenas por um aumento diário repentino - mesmo que um limite esteja definido em 5 por dia, receber dois erros 500 em 5 minutos um do outro, por exemplo, pode ser um motivo para verificar com o suporte do Rapid API.
Logs
Caso o suporte do Rapid API solicite os registros de requisição/resposta, tente fornecer o seguinte:
- O valor
Transaction-Idno cabeçalho de resposta da API. Isso é vital para investigações mais profundas. - Tanto os logs de solicitação quanto os de resposta da API. Os logs de solicitação precisam incluir o URL completo do ponto de extremidade usado. Os logs de resposta precisam incluir o código HTTP retornado, os dados de resposta completos e todos os cabeçalhos retornados.
- Solicitação à Availability API com o parâmetro
point_of_sale, bem como resposta de disponibilidade. Isso permitirá que a equipe de suporte identifique a conta e o perfil Rapid API que estão sendo usados. - Cabeçalho da solicitação da API de reservas e cabeçalho de autorização (com chave da API, assinatura e carimbo de data/hora) para cada solicitação de reserva.
- O URL e o token da solicitação de reserva nos logs de solicitação.
- A Itinerary Retrieve feita após uma chamada de reserva à API, com falha ou não.
Inclua a solicitação e a resposta JSON completas. Uma string JSON deve ser double-quoted, portanto não é necessário incluir o caractere de escape de barra invertida antes do caractere double-quote.
| Código JSON correto | Código JSON incorreto |
|---|---|
json "id": "208646250", "status": "available", | json\"id\": \"208646250\", \"status\": \"available\", |
Utilize o caractere de escape de barra invertida antes de aspas duplas somente quando as aspas duplas precisarem fazer parte da string.
Resposta de exemplo:
"spokenwords": "He said "hello world""Nota: Não coloque os registros em formato PDF. O suporte Expedia Group às vezes copia e cola dados de registro em ferramentas internas, e o formato PDF adiciona caracteres de linha desnecessários aos dados.
Anexo
Exemplo de reserva que não foi resolvida rapidamente
Exemplo de reserva confirmada
Exemplo de falha na reserva
