> ## Documentation Index
> Fetch the complete documentation index at: https://docs.drime.cloud/llms.txt
> Use this file to discover all available pages before exploring further.

# Going to Production

> Lift the 25 users limit of a new application

A new application is in **Development**: it works fully, for up to **25 connected users**. That is enough to build it, test it and show it to your first users. To open it to everyone, send it for review.

## Send it for review

Open your application in the [developer console](https://app.drime.cloud/developers) and fill in **Open it to everyone**:

| Field | What to write |
| - | - |
| **Your name or your company** | The publisher, as your users will see it |
| **What does it do?** | One or two sentences, as your users would read them (20 characters at least) |
| **What does it do with Drime?** | Which files it reads or writes, and why it needs the permissions you ticked (20 characters at least) |
| **Website** | An `https://` address |
| **Privacy policy** | An `https://` address |

Your application also needs at least one redirect URL and at least one permission. Then click **Send for review**.

Drime answers within 24 hours. Until then, your application keeps working with up to 25 users.

## What gets refused

So that you do not lose a round trip:

* a privacy policy link that does not open, or opens a blank page;
* no website, or a website that does not mention the integration;
* a name or a logo that could be mistaken for Drime itself;
* redirect URLs on a link shortener, or on an IP address other than the loopback addresses (`127.0.0.1`, `[::1]`, `localhost`) a desktop application uses;
* permissions that the description does not explain.

## If changes are requested

Your application shows **Changes requested**, with the reason. It is not a ban: it keeps its users and its 25 users limit, and you can fix what was asked and send it again.

## Before you ship

* `state` is generated for each authorization and checked when the user comes back.
* A new `code_verifier` is generated for each authorization, with `S256`.
* The secret key stays on your server: never in an app you distribute, never in version control.
* Each new refresh token is stored before it is used, and only one refresh runs at a time.
* `401` is handled by refreshing, and `invalid_grant` on a refresh by authorizing again.
* Your application asks only for the scopes it calls.
* If you use webhooks, the signature of every notification is checked.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.