Headers
You must supply a set of HTTP headers when making a request. These headers can include both standard HTTP headers and custom OCTO API or Ventrata headers.
Below are the required standard request headers, custom headers we recommend using, and useful headers you can expect in Ventrata responses.
Request Headers
Content-Type
Required
Must be application/json for all POST, PATCH, and DELETE requests.
Octo-Capabilities
Required
A list of Capabilities to include in the response, for example Octo-Capabilities: octo/pricing, octo/content. Include the header but leave it empty if no capabilities are needed. If this header is not included, Ventrata returns a 400 error.
Octo-Env
Recommended
This can mark any booking performed with live credentials as a test sale in Ventrata. This means it will not consume availability, barcodes will not work, and you will not be invoiced. 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 language. If the supplier has translated their content, it returns content in the specified language when possible, and error messages are also translated. For example, send Accept-Language: fr and the server responds with Language: fr when that language is available. See Localization.
Response Headers
Content-Type
application/json
Octo-Capabilities
A list of Capabilities initialized with your request, for example Octo-Capabilities: octo/pricing, octo/content.
Octo-Env
Returns test if the request is in test, or live if it is not, depending on your request Octo-Env value and whether the supplier forced your connection to test mode. See Live Testing.
Content-Language
The language of returned content. See Localization for how to set it.
Octo-Available-Languages
A list of languages the supplier has translated content into. See Localization.
Last updated