Genesys Cloud - Developer Community!

Hello, everyone.

I would like to understand which best practices you use to secure customer API credentials.

My goal is to avoid exposing credentials within Data Actions or Architect. I know that, in some scenarios, such as Client ID and Client Secret authentication, these can be configured directly in the web service authentication settings. However, I would like to understand what alternatives you use for more complex cases, such as APIs that require API Keys or other authentication methods.

What practices do you recommend for these scenarios?

My concern is that anyone with access to Architect could eventually gain access to customer credentials.

Thank you.

#Architect
#Integrations

------------------------------
Augusto Aranha
Gerente de Desenvolvimento de Sistemas e Planejamento
------------------------------

Hello, @Augusto Aranha

For this scenario, I would avoid storing credentials directly in Architect variables, flow logic, or hardcoded request bodies.

The safest approach, when possible, is to keep the authentication details inside the Data Action integration credentials. For example, if the external API uses Client ID / Client Secret, Basic Auth, API Key, or a custom header/token format, you can usually configure this in the Web Services Data Actions integration using the available credential types.

For more complex authentication, I would look at User Defined or User Defined (OAuth) credentials. This allows you to store the required fields at the integration level and then reference them in the Data Action request, instead of exposing the values directly in Architect.

My usual recommendations would be:

• Do not hardcode API keys or secrets inside Architect flows.

• Do not pass credentials as flow variables.

• Store secrets in the Data Action integration credential configuration.

• Use User Defined credentials for APIs that require API keys or custom headers.

• Limit who can create, edit, or view Data Actions and integrations.

• Use the principle of least privilege for OAuth clients and API users.

• Rotate credentials periodically, especially after project handover or team changes.

• If the authentication is very sensitive or complex, consider using middleware or a secure gateway between Genesys Cloud and the customer API.

In short, I would keep Architect responsible only for the business logic and keep the secrets inside the integration/authentication layer. That reduces the chance of exposing customer credentials to users who only need to maintain flows.

------------------------------
Arthur Pereira Reinoldes
------------------------------

Hi Augusto,

For Web Services Data Actions, the approach I usually recommend is to leverage the native credential management provided by the integration itself rather than storing credentials in Architect or passing them through flow variables.

For example, if the target API supports API Keys, OAuth, Basic Auth, or other supported authentication methods, configure them directly in the Web Services Data Actions integration credentials. This keeps the secret separate from the Data Action logic and prevents it from being exposed in Architect flows. The documentation on credential types is a good reference here.

For more sensitive environments, another common pattern is to have the Data Action call a customer-owned middleware/API layer. In that model, Genesys only knows the endpoint, while the actual credentials are managed externally (e.g., API Gateway, Secrets Manager, Vault, etc.).

In general, my recommendations are:

• Use the native credential management available in Web Services Data Actions whenever possible.
• Never hardcode API Keys, secrets, or tokens in Architect variables, Data Tables, prompts, or request templates.
• Restrict who has permissions to manage integrations and Data Actions.
• For highly regulated environments, consider an intermediate API layer that owns and manages the credentials.

The Web Services Data Actions integration was designed specifically to separate authentication from flow logic, which is typically the safest and most maintainable approach.

------------------------------
Gabriel Garcia
NA
------------------------------