# Registering an app

This is the first step for **an app many workspaces connect to**. If you are
integrating a single workspace, it can issue you an API key directly and you can
skip this page entirely — see [Authentication](/authentication).

An **app** is how Noé knows who is calling. You register one in the
[developer console](https://developers.wearenoe.fr), Noé reviews the scopes it
asks for, and then your customers can connect their workspaces to it.

## 1. Create an account

Sign up at [developers.wearenoe.fr](https://developers.wearenoe.fr). Registration
is open and your account works immediately.

It also grants nothing on its own, which is the point: a developer account can
register apps, but an app cannot authenticate until Noé approves it, and it cannot
read any workspace's data until that workspace authorises it. A developer session
never reaches tenant data.

Use an email that is not already a Noé login. One address is one kind of account,
so an email that already signs in to a Noé workspace cannot also be a developer.

## 2. Register the app

Give it a name, a description your customers will read on the consent screen, and
your redirect URIs.

Creating the app returns a **client id**. Create a **client secret** from the app's
page — it is shown once. You can hold several live secrets at a time, which is how
you rotate without downtime: add the new one, deploy, then revoke the old.

### Redirect URIs

Matched **exactly**. No wildcards, no prefix matching, no trailing-slash
tolerance — `https://app.example/callback` and `https://app.example/callback/` are
different URIs. Loose matching is the classic way an authorization code ends up on
someone else's server.

Register every environment you need (staging and production are different URIs).
Cleartext `http://` is only acceptable on `localhost`.

## 3. Request scopes

Request the narrowest set that makes your app work. Each scope is a separate line
on the consent screen your customers read, so asking for more than you use costs
you conversions as well as review time.

See [Scopes](/scopes) for the vocabulary. Two to know about:

- `reservations:guest_read` exposes guest names, emails and phone numbers. Every
  read is audited. Expect to justify it.
- Write scopes propagate to the connected channels, so they get more scrutiny than
  read scopes.

## 4. Submit for review

Submitting moves the app to **in review**. Noé checks:

- that the scopes match what the app plausibly does
- that the redirect URIs are exact and HTTPS
- that the name, description and logo are accurate and not misleading about who
  you are

The outcome is one of:

| Result | What it means |
| --- | --- |
| **Approved** | The scopes Noé granted are live. Your app can authenticate and customers can connect. |
| **Rejected** | Nothing works. The console shows why; fix and resubmit. |

Noé may approve a **narrower** set than you requested. The console shows requested
and approved side by side — check it before debugging an `invalid_scope` error,
because your effective access is the approved set, not the requested one.

<Callout type="info">
Approval is per app, not per developer. A second app from an approved developer is
reviewed on its own merits.
</Callout>

## 5. Optionally get listed

An approved app is **private** by default: it works, and any customer with your
authorization link can connect, but it does not appear anywhere in Noé.

Ask to be **published** and it also appears in every workspace's Marketplace,
where customers can find and connect it without a link from you.

## 6. Your customers connect

Each workspace authorises your app itself, through the
[OAuth flow](/oauth). They choose the scopes, may restrict you to a subset of
their properties, and can revoke you at any time from **Mon compte → API**.

There is no way for Noé, or for you, to connect a workspace on its behalf. That is
deliberate: consent is the workspace's decision and is recorded with who granted
it and when.

## After approval

Changing your app's name, description, logo or redirect URIs does not need a new
review. **Widening scopes does** — it goes back to in review, and your existing
grants keep working on their current scopes while you wait.

Widening also matters to your customers: a grant is capped by what they consented
to, so a newly approved scope reaches an existing customer only once they
re-authorise. Send them through the flow again to pick it up.

The console shows your own usage per app — requests, error rate and how close you
are running to your [rate limits](/rate-limits).