For the complete documentation index, see llms.txt. This page is also available as Markdown.

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

You can access the Accounts page from the Build page, by clicking the Accounts tab, or by clicking the Digibee logo in the upper-left corner, selecting Settings, and then finding the Accounts page.

The Accounts list shows the Account Name, Account Type, Description, Expiration Date, and Running Pipelines for each account, and can be filtered by Account Type, Deprecated status, and Expiration status (Expired or Expiring soon).

Creating an account

On the Accounts page, click Create new and fill in the fields:

Field
Description

Account name

A unique identifier for the account.

Account type

The type of account. Choose from the available options.

Description

Additional information about the account.

Project Availability

Defines whether the account is available to all projects or only selected ones. On the Accounts listing page, you only see accounts available to all projects or to ones you have access to.

Expiration date

Sets an expiration date for the account as a reminder: it only stops working in the pipelines if this date matches the actual expiration on the external service, in which case you'll need to update the credentials and redeploy.

Enter the date in DD/MM/YYYY format (for example, 30/05/2030). Accounts near expiration show Expires in DD/MM, and expired ones show Expired. Optional; applies only to OAuth Bearer, Private Key, Public Key, OAuth 2, Certificate Chain, Google Key, AWS V4.

Environment configuration

Credentials required for the selected account type. See below how to configure each account type.

Then 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.

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

  • 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.

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

  • 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.

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 Email V1 connector.

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.

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 list and click the row of the account you want to edit.

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. If you edit the account, any deployed pipelines must be redeployed to apply the changes.

After editing the account, click Save. A confirmation window appears, and you must click Edit to confirm the changes.

All changes are applied immediately to pipelines that use the account and have not yet been deployed. For deployed pipelines, we recommend redeploying them after editing the account to prevent issues and keep the pipelines up to date.

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:

  1. In the Accounts list, click the row of the account you want to deprecate.

  2. Enable the Deprecated toggle.

  3. Click Save.

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:

  1. In the Accounts list, click the three dots of the account you want to delete.

  2. Select Delete.

  3. Confirm the action in the pop-up window.

Using accounts

Accounts provide secure access to external services within pipelines and capsules, through connectors that support the Account field. When a connector requires one, this field appears in its configuration form so you can select the appropriate account for that integration.

When you select an account in a connector's configuration form, only the accounts allowed in the pipeline's project are shown, keeping sensitive credentials restricted to authorized projects.

Last updated

Was this helpful?