# Authentication

> Part of the OVHcloud developer hub. Index of every page and section: https://developers.eu.ovhcloud.com/llms.txt
> Everything in one file: https://developers.eu.ovhcloud.com/llms-full.txt

Every call carries a bearer token. There are two ways to obtain one, and a handful of operations need none.

## The header

A token travels in the `authorization` header, as a bearer credential. Every sample on this hub sends exactly this:

```
$ curl https://api.eu.ovhcloud.com/1.0/me \  -H "authorization: Bearer $OVH_TOKEN"
```

## A personal token

The quickest route: create one in the Console, on the identity page of your account, and keep it. It does not expire on its own, so it suits a script or a terminal session.

[Create a token in the EU Console](https://manager.eu.ovhcloud.com/#/iam/identities/users)

## OAuth2, authorization code

Reading the declared flow…

## Operations that need none

A few operations declare no security at all — availability lists, public catalogues. The reference marks each one with a Public pill, and each section header says how many it holds.

Not documented by the API: which identity to use

The specs declare one bearer scheme and one OAuth2 flow. They say nothing about how the account identities relate to one another — the OVHcloud account, IAM users, OpenStack users on Public Cloud, application keys — nor which one a given operation expects, nor how rights are granted. That explanation has to come from the API and IAM teams; it is not derivable from the documents, so this page does not attempt it.