Headers

You must supply a set of HTTP headers when making a request. These headers can include both standard HTTP headers as well as some custom OCTO API or Ventrata headers. 
Below are the required standard request headers, custom headers we recommend using, as well as some useful headers you can expect in Ventrata responses. 
Request Headers
Header
Required
Description
Authorization
Required
Your Authentication Bearer token. 
Content-Type
Required
This must be application/json for all POST PATCH and DELETE requests. 
Octo-Capabilities
Required 
A list of the Capabilities to be included in the response e.g. Octo-Capabilities: octo/pricing, octo/content, etc. Include the header, but leave it empty if no capabilities are needed. When this header is not included, Ventrata's response will result in a 400 error. 
Octo-Env
Recommended
This header can mark any booking you perform with live credentials as a test sale in Ventrata. This will mean it will not consume any availability, the barcodes will not work, and you will not be invoiced for it. UseOcto-Env: test for test bookings and Octo-Env: live to turn it off and sell live. See Live Testing. 
Accept-Language
Optional
This conforms to the regular HTTP specification for the language but if the supplier has translated their content it will return the content in the specified language if possible. Also, all error messages will be translated. eg. Accept-Language: fr the server will then respond with Language: fr depending on if that language was available. See Localization. 
Response Headers
Header
Description
Content-Type
application/json
Octo-Capabilities
A list of the Capabilities you initialized with your request.
e.g. Octo-Capabilities: octo/pricing, octo/content. 
Octo-Env
This will return test if the request is in test, or live if it wasn't, depending on Octo-Env of your request and whether or not the Supplier set your connection to be forced to test mode. See Live Testing.
Content-Language
This is the language of the content being returned. See the Localization section for info on how to set it.
Octo-Available-Languages
A list of languages the supplier has translated the content into. See Localization 

Header	Required	Description
`Authorization`	Required	Your Authentication `Bearer` token.
`Content-Type`	Required	This must be `application/json` for all `POST` `PATCH` and `DELETE` requests.
`Octo-Capabilities`	Required	A list of the Capabilities to be included in the response e.g. `Octo-Capabilities: octo/pricing, octo/content`, etc. Include the header, but leave it empty if no capabilities are needed. When this header is not included, Ventrata's response will result in a 400 error.
`Octo-Env`	Recommended	This header can mark any booking you perform with live credentials as a test sale in Ventrata. This will mean it will not consume any availability, the barcodes will not work, and you will not be invoiced for it. Use`Octo-Env: test` for test bookings and `Octo-Env: live` to turn it off and sell live. See Live Testing.
`Accept-Language`	Optional	This conforms to the regular HTTP specification for the language but if the supplier has translated their content it will return the content in the specified language if possible. Also, all error messages will be translated. eg. `Accept-Language: fr` the server will then respond with `Language: fr` depending on if that language was available. See Localization.

Header	Description
`Content-Type`	`application/json`
`Octo-Capabilities`	A list of the Capabilities you initialized with your request. e.g. `Octo-Capabilities: octo/pricing, octo/content`.
`Octo-Env`	This will return `test` if the request is in test, or `live` if it wasn't, depending on `Octo-Env` of your request and whether or not the Supplier set your connection to be forced to `test` mode. See Live Testing.
`Content-Language`	This is the language of the content being returned. See the Localization section for info on how to set it.
`Octo-Available-Languages`	A list of languages the supplier has translated the content into. See Localization

Last modified 2mo ago