Accounts
Learn more about accounts and how they are used to safely manage credentials on the Digibee Integration Platform.
Overview
Accounts provide a secure way to store sensitive information, such as passwords, private keys, and authentication tokens, without exposing these credentials directly in your integrations. By encrypting and centrally managing credentials, accounts help ensure the security of authentication processes.
Furthermore, accounts can be restricted to specific projects, ensuring that sensitive information is only accessible where it is needed. They can then be used in connectors within pipelines and capsules to authenticate and authorize access to external endpoints.
Managing accounts
Creating an account
On the Platform home page, click Settings in the upper-right corner, then select Accounts on the next page.
Click Create and fill in the fields:
Name: Identifier for the account.
Account type: Choose from the available options.
Description: Additional information about the account.
Project Availability: Define if the account can be used in all projects or only in selected ones. On the Accounts listing page, you will only see accounts that are available to all projects or the ones you have permission to access.
Accounts can be permanently removed from pipelines
Pipelines can only use Accounts that are available in their project. An Account is removed from a pipeline in the following situations:
When a pipeline is moved to another project and the Account is not allowed in the destination project.
When the Project Availability setting of an Account is updated and the project that contains the pipeline is removed from the allowed list.
Once an Account is removed in any of these situations, moving the pipeline back or allowing the project again won't restore it, for security reasons. In such cases, you must manually add each Account to the pipeline again.
Environment configuration: Credentials required for the selected account type. See below how to configure each account type.
Expiration date: Enter in DD/MM/YYYY format (for example, 30/05/2030). Accounts close to expiration show Expires in DD/MM; expired accounts show Expired. When the date matches the external service, the account stops working until you update the credentials and redeploy the pipelines. You can also filter accounts by Close to expiring or Expired. This field is optional and only applies to OAuth Bearer, Private Key, Public Key, OAuth 2, Certificate Chain, Google Key, AWS V4.
Click Save to create the account.
Configuring each account type
API Key
Description Used when an endpoint requires an API Key.
Example of connector that supports this account type includes:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
URL-PARAM-NAME: Query parameter where the API Key is applied
API-KEY: API Key value
Expiration for authentication tokens
The following providers set an expiration period for their authentication tokens. For this reason, it’s necessary to update the configurations of your accounts at the end of every period.
Expiration per provider:
Microsoft: Every 3 months
Google: Every 6 months
Mercado Livre: Every 6 months
Basic
Description Authentication with username and password.
Configuration parameters
USERNAME: User’s name
PASSWORD: User’s password
Custom Auth Header
Description Used when an endpoint requires a custom authentication header.
Examples of connectors that support this account type include:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
HEADER-NAME: Header name
HEADER-VALUE: Header value
OAuth Bearer
Description Stores an OAuth token and assigns it to the Authorization header in requests.
Examples of connectors that support this account type include:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
TOKEN: OAuth token
Private Key
Description Stores a private key for authentication.
Examples of connectors that support this account type include:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
KEY: Private key
PASSPHRASE: Private key password
Example of private key
Public Key
Description Stores a public key for authentication with public-private key pairs.
Examples of connectors that support this account type include:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
KEY: Public key
Example of public key
OAuth 2
Description Used for services that support OAuth 2.0 authorization (such as Google or Microsoft). It provides delegated access to resources without exposing user credentials.
Examples of connectors that support this account type include:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
PROVIDER: OAuth provider
SCOPES: OAuth access scopes
If a custom OAuth2 provider uses a configured certificate, a password is required. This password must match the one used when uploading the certificate. For setup details, see the OAuth2 providers documentation.
Supported providers
Microsoft: The "offline_access" scope is mandatory on the Digibee Integration Platform. It is important to remember that this provider accepts only personal accounts.
Google
Mercado Livre
OAuth 1
Description
OAuth 1 is an authentication method that enables secure communication between applications without sharing user credentials. In this case, the tokens are generated directly in the platform you want to connect to, such as NetSuite. There’s no need to log in through an external provider like Google.
Only the Oracle Netsuite connector supports this account type.
Configuration parameters
OAUTH_TOKEN: The access token generated in the platform (for example, in NetSuite) that identifies the integration user.
REALM: The account identifier or domain within the platform where the integration is performed. In NetSuite, this value usually corresponds to the account ID.
OAUTH_TOKEN_SECRET: The secret key associated with the access token. It’s also generated in the platform and used together with the token to authenticate requests securely.
Certificate Chain
Description Specifies a chain of certificates for endpoints requiring 2-way SSL authentication or client certificates. Certificates must be in PEM format and in the correct order.
Configuration parameters
CHAIN: Complete certificate chain
PASSWORD: Private key password (if required)
EXPIRATION DATE: Certificate expiration date
Example conversion with OpenSSL
Example of certificate chain
Secret Key
Description Used by encryption connectors.
Example of connector that supports this account type includes:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
KEY: Secret key
Google Key
Description Service key for accessing Google APIs.
Examples of connectors that support this account type include:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
KEY: Google key
SCOPES: Comma-separated API access scopes. See Google scopes.
Example of Google key
Kerberos
Description Stores Keytab for authentication in Kerberos environments.
Examples of connectors that support this account type include:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
KEYTAB: Base64-encoded Keytab file
PRINCIPAL: User associated with the Keytab (for example, user@DOMAIN)
AWS V4
Description Used to authenticate requests to AWS services with Signature Version 4.
Examples of connectors that support this account type include:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
SERVICE-NAME: AWS service (for example, S3, SQS)
ACCESS-KEY: AWS access key
SECRET-KEY: AWS secret key
SESSION-TOKEN: Temporary session token (if applicable)
REGION: Execution region
AWS Role
Description Grants an AWS user temporary access to a specific role created in AWS. To use this feature, an AWS V4 account must be configured.
Once both account types are configured correctly, they can be used together in connectors that support the Assume role feature.
Only the DynamoDB connector supports this feature.
Configuration parameters
ROLE-ARN: Amazon Resource Name of the role
ROLE-SESSION-NAME: Identifier for the assume role session
EXTERNAL-ID: Optional identifier for cross-account operations
Usage example
Suppose you are using the DynamoDB connector and you want a specific user to access a database to retrieve some data. You don’t want this user to always have access to this database or to perform any other operations on it. In this case, you can configure a role in AWS and allow the user to temporarily assume this role to retrieve the necessary data from the database.
To achieve this, select the AWS V4 account you want to use in the DynamoDB connector and activate the Use Assume Role parameter on the Authentication tab. When this option is active, you can select the AWS Role account that grants the user permission to perform the desired operation.
Within AWS, you must configure the AWS users who can access the role. If this configuration is not set correctly, the user of the selected AWS V4 account won’t be able to assume the role, even if both the AWS V4 and AWS Role accounts are selected in the connector.
OAuth Provider
Description Authorization via OAuth, supported only by the Salesforce connector.
Examples of connectors that support this account type include:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
CLIENT-ID: Application identifier
CLIENT-SECRET: Application secret
SMTP Auth and Properties
Description Configures SMTP credentials for sending emails with the Mail Connector.
Example of connector that support this account type include:
Store Account (for storing data dynamically)
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
HOST: SMTP server host
PORT: SMTP server port
USERNAME: Email address
PASSWORD: Email password
STARTTLS_ENABLE: “true” or “false” for SSL access
AUTH: Authentication type
NTLM
Description Microsoft security protocol suite for authentication, integrity, and confidentiality. Supported via the SOAP V3 connector.
NTLM uses outdated encryption algorithms (DES, RC4) with known vulnerabilities. Replace with Kerberos whenever possible and implement stricter security policies.
Configuration parameters
USERNAME: User’s name
PASSWORD: User’s password
DOMAIN (optional): Domain name
HOSTNAME (optional): Host name
Azure Key
Description Used to connect to Azure Key Vault. Keys can be found in the Default Directory under App Registrations:
CLIENT-ID and TENANT-ID in Overview
CLIENT-SECRET in Certificates & secrets
Examples of connectors that support this account type include:
If a connector supports this account type, it will be indicated in the Accounts parameter in its documentation.
Configuration parameters
CLIENT-SECRET: Client secret
CLIENT-ID: Application (client) ID
TENANT-ID: Directory (tenant) ID
Editing an account
To edit an account, go to the Accounts page and click the pencil icon in the Actions menu.
You can:
Update the description.
Mark the account as deprecated. Learn more about deprecating an account.
Define new rules for Project Availability.
Update credentials for all environments. Sensitive credentials won’t be visible, but you can add new ones.
View all pipelines that use the account. Note that if the account is edited, any deployed pipelines must be redeployed to apply the changes.
After editing the account, a confirmation window appears. Type “I want to edit the account” in the Confirmation message field and click Edit.
All changes are applied immediately to pipelines that use the account and have not yet been deployed.
Deprecating an account
Deprecating an account makes it unavailable for new pipelines or new pipeline versions. Existing deployments will keep working unless redeployed.
To deprecate an account:
Open the Accounts page and click the pencil icon next to the account.
Enable the Deprecated toggle.
Click Save.
This action is irreversible.
Deleting an account
Deleting an account permanently removes it from the Platform. You cannot delete accounts that are currently used in pipelines, whether deployed or not. To proceed, remove or replace the account in all pipelines before deleting it.
To delete an account:
Open the Accounts page.
Click the trash icon next to the account.
Click Delete in the confirmation window.
Using accounts
Accounts are used within pipelines and capsules to provide secure access to external services through connectors that support the Account field. When a connector requires an account, the Account field appears in its configuration form, allowing you to select the appropriate account for that integration.
Accounts are only available in pipelines created within projects where they are allowed, so sensitive credentials stay within authorized projects.
Last updated
Was this helpful?