Ezus API

What authentication does the Ezus API use?

The spec declares two security schemes: an apiKey scheme that requires the x-api-key header, and an HTTP bearer scheme used after authenticating via POST /login. Both credentials sit in your Jentic One instance, so the agent never holds the long-lived API key directly.

Can I create a travel project with the Ezus API?

Yes. POST /projects-upsert with the project payload to create or update the project in one call, and follow up with /project-steps-upsert for itinerary days and /project-travellers for the traveller list.

How do I add a supplier to the Ezus directory?

Call POST /suppliers-upsert with the supplier record to create or update it, or use POST /supplier when you want to address a single supplier explicitly; GET /suppliers lists every supplier in the account.

How do I create a project through Jentic?

Run pip install jentic, search 'create an Ezus travel project', load POST /projects-upsert, then execute it with the trip metadata; Jentic supplies both the x-api-key and the bearer token from the vault.

What are the rate limits for the Ezus API?

The spec does not declare explicit rate limits, so honour any 429 responses with backoff, batch upsert calls where possible, and avoid running unbounded /projects pulls during peak booking hours.

Can I limit what my agent is allowed to do with the Ezus API?

Yes. Because you self-host Jentic One, your own rules decide which Ezus operations and credentials the agent may use, so you can grant only what a task needs, such as GET /projects to list trips or POST /clients-upsert to sync a client. Ezus carries project and client details in the request body of its upsert routes rather than a resource id in the path, so scoping happens at the operation level: supplier calls like POST /suppliers-upsert and document routes like POST /project-documents-create stay off limits unless you add them. The x-api-key and the bearer token from /login are injected at execution time under those same rules.