Request a Client ID & Secret


Wiki User Guides LMS Developer Resources
Getting Started Guide Bentley Developer Network Authentication Python Authentication Examples Client ID & Secret Region & Instance ID .net SDK Guide
Postman Examples Postman Quick Start API Endpoints - Swagger Case Studies Other Topics
PowerBI Documentation

 

(For assistance with any of the items below, please contact support or your OpenGround Implementation Manager.)

To use the OpenGround API, you will need a Client ID, and potentially a Client Secret, depending on the Authentication method you will be using, as described below.

Important - When requesting a Client ID, please provide a brief description of your development objectives, what your application will do, and what programming languages/technologies you will be using. There is often confusion around the authentication process. Having some additional information on your development objectives will help the OpenGround team most efficiently assist you in this process.

Authorization Code with PKCE (User Login)

For User Login authentication, for development purposes, you can use the generic Client ID:

openground-cloud-connector

A Client Secret is not needed for User Login authentication.

When you are ready to deploy your app into production, we request that you use a unique Client ID. Please let us know (in the support case):

  1. The name/brief description of the app.
  2. The name of your cloud instance(s) where you will be using the app.

We can then provide a Client ID.

Redirect URIs

The following Redirect URI's can be used by default:

We can also register additional Redirect URI's for your application. In the support case, please let us know the URL's you'd like to register for each Client ID.
 
Additional Redirect URI's can not be added for the generic openground-cloud-connector Client ID. They can only be registered for custom Client ID's.
 
(Redirect URI's are only applicable to User Login authentication and are not used for Machine Login authentication.)

Client Credentials (Machine Login)

For Machine authentication, you will need to create a 'service account' user in your cloud with the appropriate access levels assigned. Assign the user a generic (fake) email address. It doesn't need to be a working email address and shouldn't be an actual user's email. The Client ID will be linked to this service account.

If you are developing multiple apps, create a service account user in the cloud for each app.

For example, below we have created 2 service account "users" - one will be associated with the Client ID for a GIS application and one that will be associated with the Client ID for a Field application. Both user accounts have been assigned as System Admins so these applications will have full access to the cloud instance.

Then, let us know (in the support case):

  1. The email address.
  2. A name/brief description of the associated app(s) so we can name the Client ID accordingly.
  3. The name of your cloud instance(s) where you will be using the app.

We can then provide a unique Client ID and Client Secret for each app.

Note - You can use the same Client ID for both your sandbox and production clouds. Or, we can create different Client ID's for each cloud instance. This is up to you and your own security requirements. We can link your clients to the service accounts in whichever cloud as you direct us to.