Credential Types in Mapp Engage

Prev Next

The Credentials area allows you to securely store and reuse access data for external systems. Instead of entering user names or passwords manually, Mapp Engage generates encrypted placeholders based on credential records. These placeholders are inserted during message creation, automation, or data transfer – protecting sensitive information from exposure in the interface.

By managing credentials centrally, you ensure consistency, reduce maintenance overhead, and meet high security standards.


1 User-related Credential Types

These credential types are used to store user-specific access data. They are primarily applied when interacting with external systems that require usernames and passwords, or when integrating with another Engage system:

  • User Name

  • User Password

  • User Account

  • CMS Account


1.1 User Name​

In the Credentials area, create a record of the type ​User Name, which encrypts only the user name. The corresponding user's password is not affected and remains unencrypted.

Example

A record with the type ​User Name​ is useful for applications with multiple users who have the same password for different user accounts. In this case, create one record with the type ​User Password​ and define a different record with the type ​User Name​ for all relevant users.

User Password Record

User Name Record

Sample FTP Path

Name: universalpassword

Name: user1

ftp://${encryption.user1.name}:${encryption.universalpassword.password}@Mapp.com

Name: user2

ftp://${encryption.user2.name}:${encryption.universalpassword.password}@Mapp.com

Name: user3

ftp://${encryption.user3.name}:${encryption.universalpassword.password}@Mapp.com

1.2 User Password​

In the Credentials area, create a record of the type ​User Password. This record encrypts the user password. The user name of the user who works with this password is not affected and remains unencrypted.

Example

A record with the type ​User Password​ is useful when different applications require the same user name but have different passwords. This discrepancy can result from, for example, different requirements for passwords. In this case, create one record with the type ​User Name​ and define a different record with the type ​User Password​ for all relevant users.

User Name Record

User Password Record

Sample FTP Path

Name: universaluser

Name: passwordx

ftp://${encryption.universaluser.name}:${encryption.passwordx.password}@Mapp.com

Name: passwordy

ftp://${encryption.universaluser.name}:${encryption.passwordy.password}@Mapp.com

Name: passwordz

ftp://${encryption.universaluser.name}:${encryption.passwordz.password}@Mapp.com

1.3 User Account​

In the Credentials area, create a record of the type ​User Account​. This record type encrypts both the user name and user password in a single record. It is also easier to insert the placeholder because the placeholder for the user name and password is generated with the name from a single record.

Example

A record with the type ​User Account​ is useful when an application requires that the user name and password are used together. To ensure that these passwords are not created separately with different names with the ​User Name​ and ​User Password​ types, use the type ​User Account​.

User Account Record

Sample FTP Path

Name: user1

ftp://${encryption.user1.name}:${encryption.user1.password}@Mapp.com

1.4 CMS Account​

For customers with multiple Mapp Engage systems, a CMS Account record can be used to interface with an external system to import CMS messages. The CMS Account type encrypts the URL of the external system and the API user's data.

The record with the ​CMS Account​ type is accessed with an API during the message creation process.

Hint:

Records with the type CMS Account cannot be reused within Mapp Engage. They are only required to interface with the external system

Example

A CMS Account record is useful when there are CMS messages in an external system that are to be imported for sendout to groups stored in a separate system.

CMS Account Record

Placeholder

Name: cmsaccount

URL: ${encryption.cmsaccount.cmsAccountURL}

User Name: ${encryption.cmsaccount.cmsAccountUser}

Password: ${encryption.cmsaccount.cmsAccountPassword}


2 Integration Credentials

Mapp Engage provides credential types that enable secure access to external systems and services used in integration scenarios. These credentials are encrypted, centrally managed, and reused in automation flows, data transfers, and API-based interactions.

Use Integration Credentials when connecting to:

  • File servers (via FTP/SFTP)

  • External APIs (via REST)

  • Cloud storage providers

  • Authentication endpoints requiring temporary tokens

  • Internal features such as Mapp Connect that trigger external systems


2.1 FTP Server

This type stores access credentials for external FTP or SFTP servers. It enables secure file transfers for imports and exports.

  • Credentials are encrypted and reused automatically across the system.

  • Updates to the login data only need to be made once in the credential record.

  • Mapp Engage supports Secure File Transfer Protocol (SFTP).


2.2 API Endpoint

Use this type to authenticate HTTP requests from Engage, for example when triggering external systems via Whiteboards or integrating with Mapp Connect.

  • Includes endpoint URL, username, and password.

  • Can be used to configure HTTP sources for automated imports.

  • Record names should be descriptive and reflect the API structure or use case.

API Endpoint

Path

Group and clone

URL: mysystem.com/API/group_and_clone.


2.3 REST Endpoint

Used to authenticate HTTP requests to APIs or external services.

Commonly used in automation jobs or with Mapp Connect integrations.

  • Store the API base path (e.g., servername/folder/folder)

  • Combine with username and password for basic authentication

  • Supports both full endpoints and base URLs depending on context

This type is ideal for push-style integrations where Engage sends data to external systems.


2.4 Token Certificate Account

Used for integrations that require a temporary token instead of a fixed password.

This token is retrieved dynamically from an authentication API.

  • Requires token endpoint, user key, API key, XPath to token, and request body

  • The token is used to authenticate subsequent API calls

  • Especially relevant for APIs that follow token-based security patterns

Setup details must be provided by the API provider or external system owner.


2.5 Cloud Storage

Credentials can also be created for accessing cloud-based storage systems. These allow Engage to retrieve or deliver files securely, without exposing access credentials in the UI.

Supported cloud services:

Amazon S3

Used to connect Engage to a specific Amazon S3 bucket.

  • Stores access key, secret key, region, and bucket name.

  • Credentials are encrypted and managed centrally.

  • One credential record per bucket is allowed.

See: Create Credential for Amazon S3 Access

Google Cloud Storage

Used to connect to a Google Cloud Storage bucket using a service account.

  • Requires a JSON file with project credentials.

  • Also requires the project ID and bucket name.

  • One credential record per bucket is allowed.

See: Create Credential for Google Cloud Storage Access