canonical: https://jentic.com/apis/ezus.io/ezus

# Ezus API

Jentic publishes the only available OpenAPI specification for Ezus API, keeping it validated and agent-ready. Ezus is a travel-agency management platform, and the API exposes the operations that travel professionals use to manage projects (trips), clients, suppliers, products, packages, destinations, invoices and webhook subscriptions. Authentication uses an x-api-key header alongside a bearer token issued by /login, supporting both delegated and machine-to-machine flows for agency back-office automation.

## For AI agents

Manage travel-agency projects, clients, suppliers, products, packages, destinations, invoices and webhooks for Ezus across 37 endpoints under api.ezus.app.

## Scope

Does not handle flight inventory, GDS bookings, or payment processing - use for travel-agency project, client, supplier and document management only.

## Capabilities

- Authenticate via /login and obtain a bearer token alongside the x-api-key header
- Create, list and upsert travel projects through /projects, /project and /projects-upsert
- Manage trip-day structure with /project-steps and /project-steps-upsert
- List and upsert clients via /clients and /clients-upsert and individual records through /client
- Maintain a supplier directory through /suppliers, /supplier and /suppliers-upsert
- Attach project documents and travellers through /project-documents and /project-travellers

## Use cases

### Project and Itinerary Management

Coordinate travel-agency operations by creating and updating projects, project steps, and traveller assignments through /projects, /project-steps and /project-travellers. Use the upsert variants to push changes from an upstream system without first checking for existence, and attach quoting or itinerary documents through /project-documents-create.

Example prompt: POST /projects-upsert with the trip metadata, then call /project-steps-upsert for each itinerary day and /project-travellers to add the traveller list.

### Client and Supplier Sync

Keep Ezus aligned with the agency's CRM and supplier database by upserting through /clients-upsert and /suppliers-upsert. Useful for travel agencies whose source-of-truth for contacts lives in a separate CRM and who need Ezus projects to reference the latest client and supplier records without manual re-entry.

Example prompt: POST the CRM client record to /clients-upsert and the supplier record to /suppliers-upsert in a nightly synchronisation job.

### Quote and Document Attachment

Generate and attach quoting documents to a project using /project-documents-create after a project has been upserted. The pattern keeps the document trail co-located with the project record and makes it easy for the agency team to retrieve the latest quote without leaving Ezus. Combine with the project-steps endpoints to ensure the quote reflects the agreed itinerary.

Example prompt: Call /project-documents-create with the rendered quote PDF and the project id to attach it to the matching Ezus project.

### Agent-Driven Travel Operations via Jentic

An AI agent supporting a travel agency can use Jentic to discover and call the right Ezus operations rather than embedding the bespoke client. The x-api-key and bearer credentials live in your Jentic One instance, so the agent can upsert clients, create projects, and attach documents while the secrets stay out of the prompt context.

Example prompt: Through Jentic, search 'create an Ezus travel project', load /projects-upsert, and execute it with the trip details supplied by the operations team.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | /login | Authenticate and receive a bearer token |
| POST | /projects-upsert | Upsert a travel project |
| GET | /projects | List travel projects |
| POST | /project-steps-upsert | Upsert itinerary steps for a project |
| POST | /clients-upsert | Upsert a client record |
| POST | /suppliers-upsert | Upsert a supplier record |
| POST | /project-documents-create | Attach a document to a project |
| POST | /project-travellers | Add travellers to a project |

## Key resources

- **Authentication** — Login and bearer-token issuance
- **Projects** — List, get, and upsert travel projects
- **Project steps and travellers** — Manage itinerary days and traveller lists
- **Project documents** — Attach quoting and itinerary documents to a project
- **Clients** — List, get, and upsert client records
- **Suppliers** — List, get, and upsert supplier records

## Why Jentic

- **Setup:** Wiring the Ezus API by hand means presenting its x-api-key, exchanging it for a bearer token at /login, targeting the api.ezus.app host, and following its upsert-style routes yourself. Through Jentic you install once, import the Ezus API from the API Directory, store the credentials once, and your agent calls it.
- **Permission scoping:** Ezus carries project and client details in the request body of its upsert operations rather than a resource id in the path, so you limit the agent to the operations it needs, such as listing projects or upserting a client. You choose those operations, so supplier or document-creation calls are not included unless you add them.
- **Credential handling:** Your Ezus x-api-key and the bearer token issued by /login are stored once, encrypted, by your own Jentic One instance and injected at execution time. The raw API key never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create an Ezus travel project' or 'upsert an Ezus client', and Jentic returns the matching /projects-upsert or /clients-upsert operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **ezBookkeeping API** — Self-hosted personal bookkeeping - useful for recording the agency's own expenses outside of Ezus invoices.
- **EZ Texting API** — SMS messaging - pair with Ezus when project updates should trigger SMS notifications to travellers.

## FAQ

### Why is there no official OpenAPI spec for Ezus API?

Ezus does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Ezus API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### 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.