Authorization

Google Docs API
Prerequisites
The Google Docs API uses OAuth 2.0 for authentication. Before creating a credential in Nexla, you will need to set up a Google Cloud project, enable the Google Docs API, and obtain OAuth 2.0 client credentials (a Client ID and Client Secret). The steps below walk through this process using the Google Cloud Console.
Step 1 — Create or Select a Google Cloud Project
-
Navigate to the Google Cloud Console.
-
Sign in with the Google account that will own the credentials.
-
In the top navigation bar, click the project selector dropdown and either:
-
Select an existing project you want to use for this integration, or
-
Click New Project, enter a descriptive project name (e.g., "Nexla Docs Integration"), select a billing account and organization if prompted, and click Create.
-
Step 2 — Enable the Google Docs API
-
In the Google Cloud Console, open the left navigation menu and go to APIs & Services > Library.
-
In the search bar, type "Google Docs API" and press Enter.
-
Click the Google Docs API tile in the results.
-
Click the Enable button. The API may take a few seconds to activate.
Step 3 — Configure the OAuth Consent Screen
Before creating OAuth client credentials, you must configure an OAuth consent screen, which defines what users see when they are prompted to authorize access.
-
In the left navigation menu, go to APIs & Services > OAuth consent screen.
-
Select the appropriate user type for your use case:
-
Internal — restricts access to users within your Google Workspace organization. This is recommended for organizational integrations where only your own Google Workspace users will authenticate.
-
External — allows any Google account to authorize. This is appropriate for integrations where end users outside your organization may need to connect their documents.
-
-
Click Create.
-
Fill in the required fields:
-
App name: Enter a recognizable name (e.g., "Nexla Docs Connector").
-
User support email: Enter a contact email address.
-
Developer contact information: Enter an email address for Google to contact regarding your application.
-
-
Click Save and Continue.
-
On the Scopes step, click Add or Remove Scopes and add the appropriate scope for your use case:
-
https://www.googleapis.com/auth/documents— Full read/write access to Google Docs documents. Use this scope when Nexla needs to both read document content and create or modify documents. -
https://www.googleapis.com/auth/documents.readonly— Read-only access to Google Docs documents. Use this scope when Nexla will only be used as a data source and no document creation or modification is required.
-
-
Click Update, then click Save and Continue through the remaining steps.
If you selected External user type and your app is in testing status, only users explicitly added to the test users list will be able to authorize the application. Add all relevant Google accounts under Test users before proceeding.
Step 4 — Create OAuth 2.0 Client Credentials
-
In the left navigation menu, go to APIs & Services > Credentials.
-
Click + Create Credentials at the top of the page and select OAuth client ID.
-
From the Application type dropdown, select Web application.
-
Enter a name for the client (e.g., "Nexla OAuth Client").
-
Under Authorized redirect URIs, add the Nexla OAuth redirect URI. Refer to your Nexla instance documentation or contact your Nexla administrator for the correct redirect URI for your deployment.
-
Click Create.
-
A dialog will display your Client ID and Client Secret. Copy both values and store them securely — you will need them when creating the credential in Nexla.
The Client Secret is only shown once in full at creation time. Store it in a secure location immediately. If the secret is lost, you can generate a new one from the Credentials page, but all existing authorizations using the old secret will need to be re-established.
Create a Google Docs API Credential
- To create a new Google Docs API credential, after selecting the data source/destination type, click the Add Credential tile to open the Add New Credential overlay.
Credential Name & Description
-
Enter a name for the credential in the Credential Name field and a short, meaningful description in the Credential Description field.
Resource descriptions are recommended but are not required. They should be used provide information about the resource purpose, data freshness, etc. that can help the owner and other users efficiently understand and utilize the resource.
OAuth 2.0 Configuration
Google Docs API credentials in Nexla use the OAuth 2.0 authorization code flow. When you connect, Nexla will redirect you to Google's authorization server, where you (or your users) can grant the requested permissions. Once authorized, Google issues an access token and refresh token that Nexla stores and manages automatically.
-
Enter the Client ID obtained from the Google Cloud Console Credentials page in the Client ID field. The Client ID uniquely identifies your application to Google's OAuth service.
-
Enter the Client Secret obtained from the Google Cloud Console Credentials page in the Client Secret field. This secret authenticates your application when exchanging authorization codes for access tokens.
-
Click the Authorize button (or equivalent OAuth flow trigger in the Nexla UI). You will be redirected to Google's sign-in and consent screen.
-
Sign in with the Google account whose document data Nexla should access, and review the requested permissions.
-
Click Allow to grant Nexla access. You will be redirected back to Nexla, and the credential will be marked as authorized.
The authorized Google account determines which documents are accessible through this credential. If you need to access documents owned by multiple Google accounts, create a separate credential for each account.
Save the Credential
-
Once all of the relevant steps in the above sections have been completed, click the Save button at the bottom of the overlay to save the configured credential.
-
The newly added credential will now appear in a tile on the Authenticate screen during data source/destination creation and can be selected for use with a new data source or destination.