APIs, described as a scoped connection, not as a public catalogue

GTOS does not publish a public API catalogue, a set of certified endpoint badges, or a self-serve developer programme on this site. Connections that a programme may need — for example employee data or finance exports — are scoped during implementation and discussed in a demo, against the systems you actually use. See HRIS and ERP for that tone in two specific domains. GTOS is the Global Travel Operating System from Voraal, built on operating experience across 100,000+ trips.

How this relates to Avunzo

Avunzo is a B2B travel API from Voraal, designed to connect travel content and booking flows to a business's own websites, apps and systems. It is not yet live on production. Early access is available on request. Avunzo is not a GTOS public API, and it should not be read as a live connection layer for the corporate operating system today.

If your interest is a channel or content API, that is the Avunzo early-access conversation. If your interest is connecting a corporate GTOS programme to your own systems, that is a GTOS implementation conversation.

Security and honesty

Any connection that eventually moves employee, trip or spend data has to respect per-client separation, access by role, and the questions in our security guide. We will not describe an open, unauthenticated interface, and we will not invent certification marks around an API we have not published.

USD is the main currency on this site. Pricing is in USD and available on request. Each company sees only its own data. We do not claim certifications we do not hold.

A demo should start with the connection you actually need, so we can say what is scoped, what is early access, and what is not available, without leaving you to infer a catalogue from this page. If the need is a channel API, that is an Avunzo early-access conversation, with the limit that Avunzo is not yet live on production. If the need is joining a GTOS programme to HR or finance, that is a scoped implementation conversation. Mixing those threads usually blurs both answers. A precise request at the start of the demo is the fastest way to get a precise boundary back. Name the system you want to join, or the channel you want to build, and keep those as two different conversations if they are two different jobs. An API discussion that tries to be both at once usually answers neither well. One job per conversation is enough.