Responses
The Deposit API response message is returned synchronously and allows Expedia Group to update the property’s system with the status of the Deposit API request. The status can either be Success or Error.
All responses provided by the API will either contain an entity
attribute,
which may represent a single object or an array of objects, or an errors
attribute
for an array of errors. Entity and errors are in the same wrapper because most frameworks will
deserialize responses automatically but require a target type to which the
response will be deserialized. Both successful and unsuccessful responses are returned by the same DTO, but can have either entity or errors, never both.
A Java implementation to handle this, using Spring’s RestTemplate, could look like this:
1ResponseEntity<ResponseWrapperDTO<RoomTypeDTO>> response =2restTemplate.exchange(3 "url",4 HttpMethod.POST,5 entity,6 new ParameterizedTypeReference<ResponseWrapperDTO<RoomTypeDTO>>() {}7);
HTTP headers
Header | Type | Format |
---|---|---|
Content-Type | String | Content-Type: application/json |
Request-ID | String | Partner-provided request identifier. If it was not provided in the request, Expedia Group will generate a Request-ID and return it in the response |
Transaction-ID | GUID | Unique transaction ID generated by Expedia Group for all messages. Expedia Group recommends storing this identifier. Can be used to reference messages when troubleshooting with Expedia Group |
Entity attribute
The only supported entity by Deposit API is the deposit policy.
The Entity approach allows you to use the same wrapper for all resources exposed by Expedia Group’s Deposit API and Product API services.
Consider the following code in Java:
1public class ResponseWrapperDTO<T> implements Serializable {2private T entity;3private List<ErrorDTO> errors;4}
Entities can be deposit policy, rate plan, room type, property, images, amenities, etc. Simple entity response:
1{2 "entity": {3 "resourceId": 123,4 ...5 }6}
Although there is only a single read operation currently supported by the Deposit API, there are two different read operations that are technically available when reading resources:
- To get a specific resource, e.g. a single deposit policy: /properties/{propertyId}/depositPolicy
- To get a list of resources, e.g. all the active room types of a property: /properties/{propertyId}/roomTypes
For example, when requesting the deposit policy of a property, the Deposit API will return the deposit policy resource information as part of an Entity object:
1{2 "entity": {3 "resourceId": 1,4 ...5 }6}
When requesting all properties assigned to a user account, an array of properties is returned:
1{2 "entity": [3 {4 "resourceId": 1,5 …6 },7 {8 "resourceId": 2,9 …10 }11 ]12}
Errors attribute
If a response doesn’t contain an entity, it will contain errors:
1{2 "errors": [3 {4 "code": 1000,5 "message": "Access denied: your account is not authorized to manage this property."6 }7 ]8}
Attributes
Attribute name | Type | Description |
---|---|---|
code | integer | |
message | string |
|