Respuestas de error habituales
Los servicios de la API comparten los siguientes códigos de error, mensajes y formatos de respuesta habituales. Consulta nuestras páginas de documentación por separado para estudiar las respuestas de error exclusivas de cada servicio.
Recomendaciones para solucionar errores de Rapid
Lógica de la resolución de errores
- Las plataformas y los colaboradores deben asegurarse de que existe una lógica de resolución de errores de compra y reserva para poder solucionar los errores de Rapid.
- Utiliza siempre un
affiliate_reference_idúnico para cada solicitud de reserva, a menos que se especifique lo contrario en las siguientes notas. - Los colaboradores deben revisar y actualizar constantemente su lógica de resolución de errores, sobre todo para las solicitudes de reserva.
- Cada respuesta de Rapid lleva su propio código HTTP; puedes consultar a continuación la lista de códigos HTTP de respuesta.
Tiempo de espera de conexión o de comunicación
Se recomienda configurar un tiempo de espera de conexión de la API de 90 segundos para las solicitudes de reserva. Aunque no existe ninguna recomendación establecida para otras API, dado que un tiempo de espera límite no conllevaría pérdidas económicas, se aconseja aplicar una configuración similar. Sin embargo, algunos colaboradores pueden decidir utilizar un tiempo de espera de conexión menor para las llamadas de disponibilidad de la compra.
Si un colaborador no ha recibido respuesta en 120 segundos, significa que no la va a recibir. Esto se debe a que EPS Rapid tiene su propia configuración del tiempo de espera, con un tiempo de espera máximo de 120 segundos. Después de dicho tiempo de espera, Rapid emitirá un error "5xx".
En algunos casos, Rapid no admite el proceso HTTP Expect: 100-Continue. Los colaboradores pueden experimentar problemas de conexión al intentar conectar servidores con el proceso, especialmente en los lenguajes cURL, C#/.NET y algunos otros lenguajes de codificación que siguen el proceso de forma predeterminada.
Nota: El error "HTTP 504 gateway time out" no implica que se haya agotado el tiempo de espera de Rapid. En estos casos, o bien ha fallado un servicio de infraestructura o bien Rapid está actuando como pasarela a otro servicio secundario y configura un límite de tiempo de espera para ese servicio. Lo que se ha activado es este tiempo límite de espera, y EPS tendrá que informar de ello como un 504. Si el 504 se produce para una llamada de reserva, debes comprobar si se ha creado la reserva o no usando Itinerary Retrieve (affiliate_reference_id+correo electrónico), ya que el problema puede ser anterior a la creación de la reserva (p. ej., comunicación con el hotel, servidor de pago) o posterior a la creación de la reserva (p. ej., gestión financiera de EPS). Comprueba también que la conexión a Internet es estable. Un comando Traceroute puede ayudar a identificar si hay problemas de conectividad.
Resolución de errores "5xx" de reserva y recuperación
Un error de reserva (estado "5xx") o un tiempo de espera agotado no significan necesariamente que la reserva en sí no sea válida, por lo que no debe sacarse esta conclusión. Es posible que el error se haya producido después de crear la reserva. En estos casos, se recomienda emitir una recuperación de itinerario con affiliate_reference_id+correo electrónico para comprobar el estado de la reserva.
Cualquier error que se devuelva en 90 segundos no indica el estado final de la reserva. Normalmente, la mayoría de las reservas se resuelven como reserva confirmada en un plazo de entre 13 y 30 segundos, aunque algunas pueden tardar hasta 90 segundos en resolverse.
Los colaboradores pueden implementar una lógica para comprobar el estado de la reserva 3 veces en un periodo de 90 segundos. La mayoría de las respuestas se confirmarán en los primeros 30 segundos, y los colaboradores podrán confirmar la respuesta sin esperar a que transcurran los 90 segundos. Si no se ha recibido una respuesta final, los colaboradores pueden volver a intentar la recuperación después de 60 segundos y, finalmente, después de 90 segundos para validar la respuesta final.
Utiliza una llamada de API de recuperación para volver a confirmar los resultados de la reserva (respuesta "HTTP 200" o "HTTP 404").
La respuesta de recuperación devuelve la información de retención y reanudación
A veces, después de una reserva que se realiza correctamente, la respuesta de Itinerary Retrieve devolverá datos de respuesta que parecen ser para una reserva de retención y reanudación. Así, en lugar de la información de reserva esperada (habitaciones, penalizaciones por cancelación, etc.), la respuesta solo tendrá los tokens necesarios para una situación de retención y reanudación.
Ejemplo de respuesta:
{
"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"
}
]
}El motivo es que la reserva, aunque es perfectamente válida, sigue apareciendo como pendiente. Este estado desaparecerá, normalmente, en cuestión de minutos, por lo que es necesario repetir las solicitudes de Itinerary Retrieve hasta que se complete la reserva.
Desglose de errores con estructura de varios niveles
La respuesta de la API puede desglosar un error en varios niveles en los casos en los que un error de un solo nivel no sea suficiente para explicar todos los detalles. La repetición de la información en todos los niveles ayudará a aclarar y solucionar mejor el error.
Ejemplo de respuesta:
{
"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 respuesta HTTP
400 - Bad Request
Aparece si tu solicitud tenía un formato o valores incorrectos.
Los errores de código "400 Bad Request" indican un problema con el encabezado de la solicitud de reserva. La respuesta del error incluirá el campo matriz del error real en el encabezado de la solicitud de reserva que se muestra como no válido. El encabezado de una reserva consta de varias matrices y submatrices, como habitaciones y pagos. La matriz general es el cuerpo. De esta forma, body.email indicaría el parámetro del correo electrónico para el cuerpo del encabezado.
Nota: La matriz de las habitaciones para el encabezado de la reserva debe tener el mismo número de entradas que las habitaciones solicitadas en la llamada de disponibilidad.
Ejemplos de respuesta:
Idiomas no aceptados:
{
"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"
}
]
}
]
}Falta el valor de la versión:
{
"type": "version.required",
"message": "You have not specified a version, the supported versions are: [1, 2]",
"fields": [
{
"name": "version",
"type": "path",
"value": "missing"
}
]
}El valor de la versión no es válido:
{
"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
Aparece si el encabezado de autorización HTTP no ha sido encontrado o no ha podido ser analizado. Cada solicitud a cualquiera de los servicios de Rapid API debe incluir el hash SHA-512 sin sal de la concatenación de tu clave para la API + secreto compartido + marca de tiempo UNIX expresada en segundos. Consulta nuestra página de verificación por firma para obtener todos los detalles.
Ejemplo de la respuesta 401 - Unauthorized:
{
"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
}
]
}403 - Forbidden
Aparece cuando tu encabezado HTTP de autorización es válido, pero no se te permite acceder al recurso solicitado.
Ejemplo de la respuesta 403 - Forbidden:
{
"type": "request_unauthorized",
"message": "Your request could not be authorized."
}404 - Not Found
Aparece si no ha podido encontrarse el recurso de la API solicitado. Compara la URL de la solicitud con los ejemplos que hemos documentado.
La API de geografía y la API de contenido también utilizan respuestas 404 para indicar cuándo no se pueden localizar los archivos geográficos o de contenido específico que se hayan solicitado. Para obtener ejemplos completos, consulta las páginas respectivas de la documentación.
El código 404 después de una recuperación de itinerario indica que no se ha podido encontrar la reserva. Si la recuperación se ha realizado debido a un error de reserva, este código indica que la reserva no se ha creado. Sin embargo, los colaboradores deben asegurarse de que los parámetros de la solicitud de la API Itinerary Retrieve eran válidos, así que comprueba siempre que el affiliate_reference_id de la recuperación, así como el correo electrónico o el número de itinerario, son correctos. Además, si la llamada de recuperación de la API se ha realizado menos de 90 segundos después de la llamada de reserva, intenta la recuperación otra vez y asegúrate de que han transcurrido más de 90 segundos desde dicha llamada de reserva.
Ejemplo de respuesta:
{
"type": "resource.not_found",
"message": "The requested resource could not be found."
}409 - Price Mismatch
Muchos alojamientos y cadenas utilizan precios dinámicos, o lo que también se denomina "precios basados en el tiempo". Esto significa que los precios varían en función de los algoritmos de la oferta y la demanda. Expedia Group recibe tarifas actualizadas de los alojamientos varias veces por segundo, lo que significa que las tarifas cambian con frecuencia.
Es importante señalar que esto suele ser decisión del alojamiento y no de EPS. Además, como se realiza un almacenamiento en caché a varios niveles para las tarifas o la disponibilidad, incluido a nivel de colaborador, puede haber varias capas de latencia en cualquier reserva.
El desajuste de precios (PMM, por sus siglas en inglés) es una situación habitual y puede darse por varias razones, incluido el deterioro de los sistemas o que estos no reflejen los precios actualizados que introduzcan los alojamientos. Los colaboradores deben vigilar la frecuencia de estos eventos y ponerse en contacto con el servicio de asistencia de EPS si el índice aumenta repentinamente o alcanza un umbral.
Si se ha producido un desajuste de precios para varios alojamientos o habitaciones al mismo tiempo, comprueba si existe un posible deterioro del servicio de Rapid.
Si el sistema devuelve un desajuste de precios para la misma tarifa o habitación durante un largo periodo de tiempo, probablemente se deba a que el alojamiento ha introducido las tarifas incorrectamente. Ponte en contacto con el servicio de asistencia técnica de EPS para comprobarlo.
Para solucionar un desajuste de precios, vuelve a realizar la llamada de la API de comprobación de precios para obtener un nuevo token de URL de reserva. Puedes utilizar el mismo affiliate_reference_id en la llamada de reserva.
Ejemplo de respuesta:
{
"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
Esta respuesta se devuelve si el enlace de Rapid que se ha usado ha caducado o si las habitaciones solicitadas ya no están disponibles.
Muchas cadenas hoteleras y alojamientos tienen enlaces de comunicación directos con Expedia Group. La comunicación síncrona es un intercambio interactivo que tiene lugar en tiempo real entre Expedia Group y los alojamientos o cadenas.
La reserva con comunicación síncrona se produce cuando el alojamiento o la cadena facilitan a EPS su inventario de habitaciones (disponibilidad y precio), el cual EPS se encarga de gestionar. Las posteriores llamadas de comprobación de disponibilidad y precio de la API de compra se realizan con estos datos. Posteriormente, en el momento de la reserva, se realiza una llamada síncrona al alojamiento para reservar las habitaciones. Este error se produce cuando no hay inventario suficiente para las habitaciones seleccionadas. Si se comprueba que el inventario es insuficiente, Rapid devolverá el código de error 410.
Puede tratarse de una situación temporal y, si se intenta otra vez, quizá se obtengan las habitaciones disponibles. Espera 90 segundos y, a continuación, comprueba el estado de la reserva con una solicitud de recuperación utilizando el mismo affiliate_reference_id que se envió con la reserva. Si no se encuentra ninguna reserva, es posible que los usuarios deban elegir otra combinación de alojamiento/habitación/tarifa/fecha.
Si hay problemas en la conexión con el alojamiento, también es posible obtener mensajes de error de "Agotado", ya que Rapid no tendrá forma de conocer la disponibilidad real.
Ejemplo de respuesta:
Enlace caducado:
{
"type": "link.expired",
"message": "The link you followed has expired. Please request a new link."
}Agotado:
"type": "rooms_unavailable",
"message": "One or more requested rooms are unavailable."426 - Upgrade Required
Aparece si la solicitud no ha utilizado TLS (sustituye a SSL).
Ejemplo de respuesta:
{
"type": "upgrade_required",
"message": "This service requires the use of TLS."
}429 - Rate Limit Errors
Nota: Si recibes un error por un exceso de solicitudes, espera al menos cinco minutos antes de intentar enviar una solicitud corregida. Si lo reintentas antes de ese tiempo, se seguirán produciendo errores debido a la sincronización de la caché.
Cuando el recuento de solicitudes supera el límite de cuota, se devuelve un código de estado 429. Cada respuesta puede ser sometida a dos límites de cuota diferentes: una en la que una integración está enviando solicitudes a una velocidad superior al límite y otra en la que los servidores de Expedia Group están sufriendo una carga que sobrepasa el límite.
Cuando un colaborador realiza una solicitud de la API de Expedia Group, el servidor que la recibe comprueba si el recuento de solicitudes está dentro del límite. Si el recuento de solicitudes está dentro del límite, la solicitud prosperará y se incrementará el recuento para el cliente. Si el recuento de la solicitud del cliente sobrepasa el límite, el servidor devolverá una respuesta con un código HTTP de estado 429 (demasiadas solicitudes).
El servidor puede incluir, de forma opcional, un encabezado Rate-Limit-Day-Reset y Rate-Limit-Minute-Reset. Indica cuánto tiempo deberías esperar antes de enviar siguiente solicitud. Se trata de las marcas de tiempo en las que se producirá la siguiente caída, expresadas en microsegundos (no en milisegundos).
Por ejemplo, cuando se convierten a una fecha u hora, el valor "15489792000000" da como resultado Friday, February 1, 2019 12:00:00 AM (UTC).
Ejemplo de respuesta:
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
Devuelve un error presente en Rapid API o en los sistemas que preceden en la cadena. Sigue las instrucciones del campo del mensaje si se indica una acción específica; de lo contrario, intenta realizar la solicitud otra vez con el mismo affiliate_reference_id.
Rapid responde con un HTTP 500 cuando detecta un problema, pero no puede ofrecer más detalles sobre este. Al utilizar Rapid es normal que, de vez en cuando, se reciban respuestas de código 500.
También se puede producir un error HTTP 500 cuando se utiliza un punto de venta no compatible, como Siria.
Si has recibido un error en una respuesta de la API que no sea "Crear reserva" o "Cancelar reserva", y no parece haber ningún problema de conexión, vuelve a intentar la solicitud en otro momento. Puede que incluya un encabezado Retry-After para indicar el retardo mínimo (en segundos) antes de volver a intentarlo.
Si has recibido un error en la respuesta de la API al crear una reserva:
- Espera 90 segundos y, a continuación, comprueba el estado de la reserva con una solicitud de recuperación utilizando el mismo
affiliate_reference_idque se envió con la reserva. - Si no se encuentra ninguna reserva o sigues recibiendo el error 500, vuelve a intentar la reserva más tarde.
Si has recibido un error en la respuesta de la API al cancelar una reserva:
- Espera 90 segundos y, a continuación, comprueba el estado de la reserva con una solicitud de Itinerary Retrieve utilizando el
itinerary_idconocido. - Si la reserva no se cancela o sigues recibiendo el error 500, vuelve a intentar la cancelación más tarde.
Ejemplos de respuesta:
{
"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
El error HTTP 503 suele ser temporal e indica que Rapid, o un servicio posterior, no puede gestionar la solicitud en ese momento. Hay varias razones posibles, desde una sobrecarga temporal hasta la pérdida de la conexión con el alojamiento.
Si has recibido un error en una respuesta de la API que no sea "Crear reserva" o "Cancelar reserva", y no parece haber ningún problema de conexión, vuelve a intentar la solicitud en otro momento. Puede que incluya un encabezado Retry-After para indicar el retardo mínimo (en segundos) antes de volver a intentarlo.
Si has recibido un error en la respuesta de la API al crear una reserva:
- El enlace de la reserva generado en tu respuesta previa de comprobación de precios caduca tras un breve periodo de tiempo. Si, tras el primer intento, se te muestra un error HTTP 503, es probable que el enlace haya caducado. Deberás obtener un nuevo enlace y realizar un nuevo intento de reserva.
- Si recibes un 503 en el segundo intento, espera 90 segundos y, a continuación, comprueba el estado de la reserva con una solicitud de recuperación utilizando el mismo
affiliate_reference_idque se envió con la reserva. - Si no se encuentra ninguna reserva o sigues recibiendo el error 503, vuelve a intentar la reserva más tarde.
Si has recibido un error en la respuesta de la API al cancelar una reserva:
- Espera 90 segundos y, a continuación, comprueba el estado de la reserva con una solicitud de Itinerary Retrieve utilizando el
itinerary_idconocido. - Si la reserva no se cancela o sigues recibiendo el error 503, vuelve a intentar la cancelación más tarde.
Ejemplo de respuesta:
{
"type": "service_unavailable",
"message": "This service is currently unavailable."
}504 - Gateway Time Out
El error HTTP 504 no suele proceder de Rapid, sino de la nube o de la infraestructura periférica, e indica que un elemento de la infraestructura de red (como el equilibrador de carga) ha experimentado un problema durante la transacción. Normalmente se trata de un evento temporal.
Ten en cuenta que el tiempo de espera puede agotarse antes o después de la creación del itinerario, por lo que deberás comprobar siempre si el itinerario se ha creado o no.
Las respuestas con error HTTP 504 (y 502) emplean el formato HTML en lugar del par de objetos tipo/mensaje en formato JSON de Rapid. Esta es otra indicación de que estos errores no los genera Rapid.
Ejemplo de respuesta:
<html>
<head><title>504 Gateway Time-out</title></head>
<body>
<center><h1>504 Gateway Time-out</h1></center>
</body>
</html>Tasa umbral de respuestas erróneas
A fin de establecer sus propios umbrales, los colaboradores deben medir la tasa diaria de los siguientes códigos de respuesta: 409, 410, 500, 503 y 504. Si se supera el umbral, deberán ponerse en contacto con el servicio de asistencia de EPS.
EPS no tiene establecido ningún umbral fijo, ya que, entre otros factores, depende del mercado en el que se encuentren los colaboradores y los mercados a los que vendan. Así pues, es fundamental conocer a fondo el mercado para determinar por qué se producen algunas respuestas de error. A modo orientativo, es habitual que entre el 5 y el 6 % de las llamadas de reserva devuelvan un error de código "50xx" a lo largo de un día o una semana.
Con el tiempo, los colaboradores deberían poder calcular sus propios umbrales. No es recomendable que se limiten a buscar un aumento diario repentino. Aunque se establezca un umbral de 5 al día, la obtención de dos errores "500" con 5 minutos de diferencia, por ejemplo, puede ser motivo de consulta al servicio de asistencia de EPS.
Registros
Si EPS solicita los registros de solicitud/respuesta, intenta proporcionar lo siguiente:
- El valor
Transaction-Iddel encabezado de respuesta de la API. Esto es fundamental para investigar a fondo el caso. - Los registros de solicitudes y respuestas de la API. Los registros de solicitudes deben incluir la URL completa del punto de conexión utilizado. Los registros de respuestas deben incluir el código HTTP devuelto, los datos completos de las respuestas y cualquier encabezado que se haya devuelto.
- La solicitud de la API de disponibilidad con el parámetro
point_of_sale, así como la respuesta de disponibilidad. Esta información permitirá al servicio de asistencia de EPS identificar la cuenta de Rapid y el perfil que se ha utilizado. - El encabezado de la solicitud de la API de reserva y el encabezado de autorización (con APIKey, firma y marca de tiempo) para cada solicitud de reserva.
- La URL de la solicitud de reserva y el token que aparecen en los registros de solicitudes.
- La recuperación de itinerario emitida después de una llamada de la API de reserva, independientemente de si dicha llamada se ha realizado correctamente.
Incluye también la solicitud y la respuesta JSON completas. Una cadena JSON debe ir debidamente entrecomillada, por lo que no es necesario incluir el carácter de escape de barra invertida delante del carácter de comillas dobles.
| Código JSON correcto | Código JSON incorrecto |
|---|---|
| json "id": "208646250", "status": "available", | json\"id\": \"208646250\", \"status\": \"available\", | |
Utiliza el carácter de escape de barra invertida delante de unas comillas dobles solo cuando necesites que las comillas dobles formen parte de la cadena.
Ejemplo de respuesta:
"spokenwords": "He said "hello world""No pongas los registros en formato PDF. El servicio de asistencia de EPS y los desarrolladores a veces copian y pegan los datos de registro en sus herramientas internas, y el formato PDF añade caracteres de salto de línea innecesarios a los datos.
Apéndice
Booking that has not resolved quickly.
Confirmed booking.
Booking failure.
