Genesys Cloud - Developer Community!

Hi everyone,
I'm currently implementing an integration using Genesys Cloud Digital Bot Connector v2,  where our custom service acts as a BCSP (Bot Connector Service Provider) as described in the official documentation:
developer.genesys.cloud/commdigital/textbots/...
We are building a BCSP-compliant endpoint to handle bot interactions (web messaging or whatsapp) from Genesys Cloud.
The BCSP is deployed on Google Cloud Run.
Genesys Cloud (Digital Bot Connector) calls our BCSP via HTTPS following the customer API spec.
 
From the architecture described in the documentation:
- Genesys Cloud acts as the client
- Our service implements the BCSP interface

The BCSP model appears to rely on static configuration of HTTP headers for authentication (e.g., API keys or bearer tokens configured in the integration).
However, in our environment (GCP / Cloud Run), standard best practices typically involve, for example, short-lived OAuth2 access tokens or IAM-based authentication. 
 
This creates a mismatch because the Digital Bot Connector does not seem to support dynamic token retrieval or refresh
and we cannot directly use GCP-native identity-based authentication from Genesys.

I would like to understand how others approached this in real implementations of a BCSP.
How are you securing your BCSP endpoint?

If you are using tokens:
- How do you handle token rotation?
- Are you using long-lived credentials or rotating them manually?

Have you introduced an intermediate component between Genesys Cloud and the BCSP?

For those using Cloud Run, have you:
- Exposed the BCSP as a public endpoint with custom auth?
- Or implemented a proxy layer to bridge Genesys with IAM-protected services?
- Found a way to leverage Identity Tokens / service accounts in this setup?

Any feedback, reference architectures, or lessons learned from production BCSP implementations would be extremely helpful.
Thanks!

#Integrations
#WebMessaging

------------------------------
Marco Brunetti

------------------------------

Hello Marco, 

The Digital Bot Connector (v2) currently supports two primary methods for authenticating requests to your BCSP endpoint:

Connection Secret
Mutual TLS (mTLS)

The most common approach is the Connection Secret, where you configure a header name and value in the Digital Bot Connector integration. That header is included with every request sent to your BCSP, and it's up to your service to validate it. If the header is missing or invalid, your endpoint should return a 403 Forbidden response.

This is a static credential. I couldn't find any support for dynamically retrieving tokens or automatically refreshing credentials, so your understanding is correct.

For environments where stronger authentication is required, you can also enable mTLS. This uses certificate-based authentication instead of relying solely on a shared secret, but it still doesn't provide a mechanism for rotating short-lived tokens or integrating directly with cloud IAM services.

Regarding GCP Cloud Run, I don't see a native way for Genesys Cloud to authenticate directly with GCP IAM or use Identity Tokens, but just because I don't see it doesn't necessarily mean it cant be done. The current model appears to assume long-lived credentials rather than OAuth2 or cloud-native authentication patterns.

If I were deploying this on Cloud Run, I'd probably consider one of these approaches:

Use a lightweight proxy or API Gateway between Genesys Cloud and Cloud Run. The proxy can validate the static Connection Secret from Genesys Cloud and then authenticate to Cloud Run using GCP Identity Tokens. This lets you keep your backend protected with IAM while presenting the authentication model that Genesys expects.
Expose the Cloud Run service and implement your own authentication. In this model, your application validates the Connection Secret on each request. I'd recommend storing the expected secret in Google Secret Manager rather than hardcoding it.

If security requirements are particularly strict, you could also combine the Connection Secret with your own request validation or signing mechanism to add another layer of protection.

Overall, I think the proxy approach is probably the cleanest solution because it bridges the gap between Genesys Cloud's static authentication model and GCP's identity-based authentication.

One thing I wasn't able to find in the documentation is any reference architecture for cloud-native deployments (GCP, AWS, or Azure), or guidance around automated token rotation, again not saying it can't be done.

Based on the available documentation, that doesn't appear to be a supported capability today, so if dynamic token rotation is a hard requirement, it would likely need to be implemented outside of the Digital Bot Connector itself.

Hope this helps!

------------------------------
Cameron
Online Community Manager/Moderator
------------------------------