The v2 API is built around two simple ideas: an organization owns one or more projects, and you always act on behalf of a single project. Understanding this scoping model up front makes every request -- and every response -- easy to reason about.Organizations#
An organization represents your company or account. It owns your projects, your billing, and your team members. Most integrations operate within a single organization.Projects#
A project is an isolated, self-contained workspace -- the unit you authenticate as. Everything you work with belongs to a project: its enriched hotels, its text templates, its generated texts, and the API keys that reach them. Two projects never see each other's data.You tell the API which project a request applies to with the X-Project-ID header, and your project API key is bound to that same project. Together they scope every call to one project's data.The platform is multi-tenant, and a project is the tenant boundary. All isolation -- data, access, and experimentation -- happens at the project level.
Why Projects#
Isolation -- each project's content and configuration are fully separated from every other project.
Multiple brands or sites -- run several projects under one organization, each with its own templates and content.
Granular access -- issue API keys per project, so a key only ever reaches that one project's data.
Experiment with a Dedicated Project#
There is no separate sandbox environment and no second base URL. Because each project is an isolated tenant, the way to test safely is to create a dedicated project for experiments. Generate texts, try out templates, and explore the API there without touching the content your production project serves. When you are happy with the result, do the same in your production project.Point your experiments at a separate project. Its hotels, templates, and generated texts are completely isolated from your production project, so you can iterate freely and throw the experiment away when you are done.
API Keys and Projects#
A project API key (Bearer proj_...) authenticates your request and identifies which project you are acting as. Send it together with the matching X-Project-ID header on every call; if the two disagree, the request is rejected. See Authentication for the details.Need help? Reach our integration team at integrations@ygo.ai. 