OpenAPI spec Servers url parameter in YAML needs to be set dynamically by OAuth2

Does anyone have a solution to this use case? Sample YAML OpenAPI spec?

As an end user of Leankor, a project and work management system running within the Salesforce Cloud, I want to use the LeankorGPT in the OpenAI GPT store; however, I have my own Salesforce instance “companyname-1234.my.salesforce.com” and this is my endpoint url for all Restful API calls. Other customers of Leankor will have their own company name in the domain name. Moreover, if I spin up a few sandboxes they too will have their own unique domain names.

So the issue is from what I can tell, in GPT Builder I have to hard code a url endpoint for the Actions under “Servers” in the YAML spec. I know I can make a dyanmic variable in the url of the Servers section but then how do I instruct GPT Builder to use return “endpoint” parameters in OAuth2 responses to dynamically set the url?

PS: In the distant past all Rest calls used to be to a “known” enpoint such as login.salesforce.com but this is not secure and many global customers are locking API calls to their own custom domains these days.

You can’t dynamically change the server for your GPT Actions. You will need to create a proxy that forward requests to each custom server (and falls back on login.salesforce.com when a custom server isn’t supplied), and that proxy service will act as a middleperson between your GPT and the Salesforce APIs.

I understand the proposed solution but it does seem like a rather large unexpected lift vs. the initial problem statement. I will research the situation a bit more …

From ChatGPT below. @huwsername

So does this mean all these 1000’s of developers cannot build actions for customers using all these clouds? The endpoint url is dynamic and unique to each customer and different from the oauth2 URI.


The blueprint of using customer-specific instance URLs with unique domains for each customer, similar to Salesforce’s approach, is also utilized by several other large, multi-tenant cloud services and SaaS platforms. This design allows these services to provide a personalized, scalable, and secure environment for each customer. Some notable examples include:

  1. Microsoft Office 365 and Azure:

    • Microsoft uses a tenant-specific model for its Office 365 services. Each tenant gets a unique subdomain, especially for SharePoint and related services.
    • Azure services also often provide customer-specific endpoints, particularly for Azure Active Directory and related identity services.
  2. Oracle Cloud:

    • Oracle Cloud services, particularly their SaaS offerings like Oracle Fusion, use customer-specific URLs to provide dedicated instances for each customer.
  3. SAP Cloud Platform:

    • SAP offers customer-specific subdomains, especially in their cloud and SaaS offerings like SAP SuccessFactors and SAP Cloud Platform.
  4. Amazon Web Services (AWS):

    • While AWS generally uses a more centralized approach for services like S3 or EC2, certain AWS services like Amazon Chime or AWS Single Sign-On can utilize customer-specific URLs.
  5. IBM Cloud:

    • IBM Cloud services, including Watson services, provide customer-specific URLs for accessing various cloud resources and AI services.
  6. Atlassian Cloud:

    • Atlassian’s cloud products, like Jira and Confluence, offer customer-specific subdomains. Each customer’s instance is accessed through a unique Atlassian.net subdomain.
  7. HubSpot:

    • HubSpot provides customer-specific subdomains for accessing their marketing, sales, and service hub platforms.
  8. Zendesk:

    • Zendesk uses a model where each customer has their own subdomain for accessing the Zendesk support and ticketing system.
  9. ServiceNow:

    • ServiceNow, a cloud-based IT Service Management tool, often uses customer-specific instance URLs for different organizational tenants.

These platforms adopt this architecture primarily to offer scalable, isolated, and secure environments for each of their customers. It allows them to efficiently manage multi-tenant infrastructures, ensuring that each customer’s data and configuration settings are separated. This approach also facilitates more straightforward customization and personalization for each customer’s instance.

Nah, those customers can—either they just build a one-off Action specifically for their instance, or they write a proxy. Both are well within the realm of possibility.

I’ve done a poll. No business customers will do it. They want my GPT to just work. Not a very technical audience.

Looks like I am going to have to learn Amazon’s API Gateway scripting and build something this weekend.