The App Console lets you manage settings and view information related to your Grammarly for Developers app. You’ll be taken to the App Console when you create a new app or select an existing app from My Appsopen in new window.
There are some actions that only the app owner (the person who created the app) can perform.
Within the App Console, the menu on the left contains several options:
- Dashboard takes you to your app’s dashboard of usage analytics.
- Collaborators is where you can invite and manage team members. It only appears for the app owner.
- Connected Accounts lets you turn on connected accounts for your app.
- Dictionaries lets you create and manage dictionaries for your app.
- Manage Plan lets the app’s owner manage the plan for their application, including the payment details for advanced communication features.
- Trusted Authentication is where you can set up trusted authentication for your app.
- Settings is where you can rename or delete your app. Note that only the app owner can delete the app.
- Clients lets you add different platforms where your app is available. See more details below.
Your app is created with a web client by default. If your app is also available on desktop, you can add a desktop client. Each client will have unique credentials for connecting to Grammarly.
You can add clients using the Add client button in the left menu. You can rename and delete clients from the page for each client.
If you use multiple development environments (e.g., qa/dev/prod), we recommend creating a separate Grammarly for Developers app for each environment rather than using clients. Each app can have up to two trusted authentication keys per app, and if you decide to turn on trusted authentication, it’s a best practice for each environment to have its own key.
Only alphanumeric characters, and symbols like
+ (plus), and the blank space are allowed in the client name.
Quick start guide
By default, each client page will show you a quick start guide explaining how to use the Grammarly Text Editor SDK for web or desktop. Once you’re done reading the guide, you can select Done with Quick Start to dismiss it.
Below the quick start guide, you’ll find the client’s Credentials. Here, you can view your client ID, which the SDK uses to authenticate your requests. You can also configure origins (for web clients) and redirect URIs (for desktop clients). For more about how these credentials work and why you might want to additionally consider setting up trusted authentication, see Securing Your Integration.
Origins (web clients)
For a web client, you must configure allowed originsopen in new window. Grammarly will only allow the origins that you configure here to communicate with Grammarly's cloud using your application's client ID. You can add multiple allowed origins for your application. Each origin must include the protocol (e.g.
https://) and domain; you may optionally specify a port.
- Origins can include the wildcard character
*to permit all requests originating from your domain. Example:
- If you're specifying a port, include the port after the domain. Example:
https://*.example.com:8080. You can also use the wildcard character
:*to allow communication from any port that is not the default port. Example:
https://www.example.com:*. If you're using the default port, do not append
When you create a new application, Grammarly automatically adds
http://127.0.0.1:* to the origins list to simplify development.
Redirect URIs (desktop clients)
For a desktop (Electron) client, you can configure redirect URIs in the Credentials section. These are the URIs Grammarly can redirect to after a user attempts to connect their Grammarly account to your application. Redirect URIs are needed to turn on connected accounts for your desktop application.
Grammarly validates each redirect URI as described in the bulleted list below. If you feel your URI is being incorrectly marked as invalid, please create an issue in the Grammarly for Developers GitHub repositoryopen in new window.
- The redirect URI must use well-known schemesopen in new window such as HTTP and HTTPS.
- Other schemes, like FTP, Telnet, and other common application protocols are not allowed.
- The redirect URI must not use wildcard characters, non-printable ASCII characters, or null characters.
- The redirect URI must not contain a path traversal (e.g.
- The redirect URI must not contain the userinfo subcomponentopen in new window.
- The redirect URI must not contain a fragmentopen in new window identifier component.
- The redirect URI must have a domain. Domains with non-Latin characters can be Punycodeopen in new window encoded.