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.
An app is how Noé knows who is calling. You register one in the developer console, 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. 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 for the vocabulary. Two to know about:
reservations:guest_readexposes 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.
Approval is per app, not per developer. A second app from an approved developer is reviewed on its own merits.
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. 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.