Credentials in Nexla
Credentials are resources that allow users to connect to and exchange data with external data systems through Nexla.
1. Credentials in Nexla
Credentials contain the authentication information that is required to connect to external data systems, such as databases, APIs, file systems, email systems, smart devices, and many others. This authentication information can include, for example:
- the server location and user information required to access an FTP server;
- the authentication type and associated keys, ID, or instance information for Amazon S3; or
- the system access token for Facebook Ads.
In Nexla, credentials are resources that can be viewed, edited, and shared like any other resource.
2. Creating a New Credential
New credentials can be created in Nexla during the process of creating a new data source/destination or directly from the Credentials screen in the Integrate section.
For general information about creating a new credential, see Create a New Credential. Specific instructions for creating a new credential for each connector type can be found in the pages in the Connectors section.
3. Reusing Credentials
Credentials only contain information about about how to access an external data system and do not define the details of reading/writing data from that system.
Therefore, a single credential can be used to set up multiple data sources/destinations of the corresponding type. Reusing credentials whenever possible is recommended—this simplifies the process of updating the authentication information for an external data system when necessary.
Information that instructs Nexla how data should be read from a or written to a data system is saved in each source/destination. The credential corresponding to the data system is used to authenticate access to the data system, and all details about reading or writing data are included in the information entered during data source/destination creation.
For more information about configuring data read/write instructions, see the articles in the Connectors section.
A single Snowflake credential can be used to ingest data from multiple locations within a Snowflake database.
First, create a Snowflake credential that autheticates to the Snowflake database.
Then, use that credential to create multiple data sources/destinations, selecting the appropriate table within the Snowflake database for each.
4. Managing Credentials
Complete information about managing credentials, including sharing, editing, and deleting credentials as well as managing user accesses, is found in View & Manage Credentials.
The sections below provide general information about different credential management functions and links to specific sections within the above page that address each function.
Credential Sharing & Access Managment
In Nexla, credentials can be shared with other users without compromising sensitive account information. When a credential is shared, recipient users can use the credential to create data sources and/or destinations, but they do not receive sensitive information such as passwords and access keys associated with the credential.
To learn how to share credentials with other users, see Section 3.1: Share a Credential in View & Manage Credentials.
Manage User Access to a Credential
For credential owners and users with administrator-level access to a credential, Nexla provides complete control over user accesses to the credential. Existing accesses can be modified to assign a different access level to the recipient user(s) or deleted to remove credential access.
To learn more about credential management and how to perform these functions, see Section 3.2: Manage Credential Access in View & Manage Credentials.
5. FAQs
Credentials Marked as Invalid
A credential will be marked as invalid if Nexla fails to authenticate to an external data system using that credential at any point. The invalid marker indicates that the credential can no longer be used to access the external data system.
Credentials Screen:
Data Source/Destination Creation Screen:
Typically, a credential is marked as invalid when Nexla cannot authenticate to the associated external data system during one of the following scenarios:
- A user attempts to create a new data source or destination using the credential
- A read or write operation was triggered in a data flow that includes an active data source or destination using the credential
- The credential has a periodic auto-refresh requirement—for example, a credential using OAuth-based authentication—and the platform is unable to fetch a new token during the periodic refresh interval
- A user tests the credential to verify its validity
Testing Credential Validity
The validity of an existing credential can be tested without using the credential to create a new data source or destination. This is useful, for example, when managing shared credential resources.
To test a credential for validity:
Locate the credential in the Credentials screen of the Integrate section.
Click on the credential to open its information drawer, and click the
button. 
If Nexla successfully establishes a connection with the external data system using the credential, the
icon will be displayed at the top of the information drawer. 
If Nexla is unsuccessful in establishing a connection with the external data system using the credential, the
icon will be displayed at the top of the information drawer. 
REST APIs: Validation URLs
For step-by-step instructions for creating a generic REST API credential in Nexla, see Section 1: Credentials in the REST API (Generic) article.
Nexla includes custom connectors for some REST API-based systems. To learn how to create a credential for these data systems, see the articles in the Connectors/REST API-Based Systems section.
For a REST API-based credential, the Credential Validation URL is a valid endpoint used to test the validity of the credential. Because this endpoint is only used to confirm the credential validity, it does not need to be the same as the endpoint accessed to read or write data.
When selecting the validation URL, using an endpoint that does not trigger long computations in the external data system is recommended.
Example recommended validation URLs include:
- An endpoint that provides user information
- An endpoint that provides metadata
- An endpoint that fetches a small number of valid records, such as
fetch any order item.
REST APIs: Periodic Refresh
Nexla includes full support for REST API credentials that require periodic refreshing—the platform includes a smart refresh-detection mechanism that automatically maintains active authentication tokens for any REST API.
Token-Based Authentication:
To enable periodic token refreshing for REST API connectors that use a token-based authentication mechanism, no additional configurations are required during credential creation. Nexla will automatically attempt to fetch a new token from the token URL when the current token expires.
OAuth 2.0 Authentication:
For REST API connectors that use an OAuth 2.0-based authentication mechanism, automatic token refreshing can be enabled during credential creation.
In the credential creation screen, check the box next to Requires Auto-Refresh of Token to enable automatic periodic token refreshing for the credential, and enter the token-refresh URL in the Refresh Token URL box.
When this setting is enabled, Nexla will automatically fetch a new token from the token-refresh URL before the current token expires.
OAuth 2.0-based API vendors may limit how long a backend server can continuously refresh tokens. When this limit is reached, users must re-authenticate the credential from the user interface.