starred/hoppscotch

Fork 0

mirror of https://github.com/hoppscotch/hoppscotch.git synced 2026-04-25 08:45:58 +03:00

[GH-ISSUE #5824] [feature]: Support Multiple Servers from OpenAPI Spec with Variable Generation #2282

New issue

Open

opened 2026-03-16 23:50:21 +03:00 by kerem · 4 comments

kerem commented

2026-03-16 23:50:21 +03:00

Owner

Originally created by @Leon-Luu on GitHub (Feb 2, 2026).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5824

Is there an existing issue for this?

I have searched the existing issues

Summary

When importing an OpenAPI specification that contains multiple servers (e.g., for different environments like production, staging, and development), Hoppscotch currently only uses the first server URL and ignores the rest.

openapi: 3.0.3
info:
  title: Example API
  version: 1.0.0
  description: An example API with multiple server environments and common HTTP methods.

servers:
  - url: https://api.example.com/v1
    description: Production server
  - url: https://staging-api.example.com/v1
    description: Staging server
  - url: https://dev-api.example.com/v1
    description: Development server

Current behavior in Hoppscotch:

Only https://api.example.com/v1 is used
Other server URLs are discarded
No way to easily switch between environments

Desired Behavior (Postman's Approach)
When Postman imports the same OpenAPI spec with multiple servers, it:

Generates a {{baseUrl}} variable automatically
Creates a collection variable with the first server as default value

Proposed Solution for Hoppscotch

On OpenAPI import, detect multiple servers in the spec
Generate a <> environment variable
Set the first server as default value

Why should this be worked on?

Environment flexibility: Easily test against different environments
Better DX: Matches developer expectations from other API tools
Standards compliance: Properly utilizes OpenAPI spec features
Workflow improvement: No manual URL replacement needed

Originally created by @Leon-Luu on GitHub (Feb 2, 2026). Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5824 ### Is there an existing issue for this? - [x] I have searched the existing issues ### Summary When importing an OpenAPI specification that contains multiple servers (e.g., for different environments like production, staging, and development), Hoppscotch currently only uses the first server URL and ignores the rest. ``` openapi: 3.0.3 info: title: Example API version: 1.0.0 description: An example API with multiple server environments and common HTTP methods. servers: - url: https://api.example.com/v1 description: Production server - url: https://staging-api.example.com/v1 description: Staging server - url: https://dev-api.example.com/v1 description: Development server ``` **Current behavior in Hoppscotch:** Only https://api.example.com/v1 is used Other server URLs are discarded No way to easily switch between environments <img width="753" height="140" alt="Image" src="https://github.com/user-attachments/assets/c2e10e0e-5ddc-431f-8c89-1bee4263b242" /> **Desired Behavior (Postman's Approach)** When Postman imports the same OpenAPI spec with multiple servers, it: Generates a {{baseUrl}} variable automatically Creates a collection variable with the first server as default value <img width="830" height="304" alt="Image" src="https://github.com/user-attachments/assets/906a8dc3-cd10-45b5-a303-6776901c7d24" /> <img width="798" height="199" alt="Image" src="https://github.com/user-attachments/assets/142fdc10-90f4-4b8d-8abf-7fdb5ac22982" /> **Proposed Solution for Hoppscotch** - On OpenAPI import, detect multiple servers in the spec - Generate a <<baseUrl>> environment variable - Set the first server as default value <img width="733" height="230" alt="Image" src="https://github.com/user-attachments/assets/94e0b196-6a50-4e0f-9a18-e6344f91b59d" /> ### Why should this be worked on? - Environment flexibility: Easily test against different environments - Better DX: Matches developer expectations from other API tools - Standards compliance: Properly utilizes OpenAPI spec features - Workflow improvement: No manual URL replacement needed

kerem added the

feature

label

2026-03-16 23:50:21 +03:00

kerem commented

2026-03-16 23:50:32 +03:00

Author

Owner

@Leon-Luu commented on GitHub (Feb 2, 2026):

Adding a simple test openapi spec if anyone would like to test:

openapi: 3.0.3
info:
  title: Example API
  version: 1.0.0
  description: An example API with multiple server environments and common HTTP methods.

servers:
  - url: https://api.example.com/v1
    description: Production server
  - url: https://staging-api.example.com/v1
    description: Staging server
  - url: https://dev-api.example.com/v1
    description: Development server

paths:
  /items:
    get:
      summary: Get list of items
      responses:
        '200':
          description: A list of items.
          content:
            application/json:
              schema:
                type: array
                items:
                  $ref: '#/components/schemas/Item'
    post:
      summary: Create a new item
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/NewItem'
      responses:
        '201':
          description: Item created successfully
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Item'

  /items/{itemId}:
    parameters:
      - in: path
        name: itemId
        required: true
        schema:
          type: string
        description: The ID of the item
    get:
      summary: Get an item by ID
      responses:
        '200':
          description: Item details
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Item'
        '404':
          description: Item not found
    put:
      summary: Update an item by ID
      requestBody:
        required: true
        content:
          application/json:
            schema:
              $ref: '#/components/schemas/UpdateItem'
      responses:
        '200':
          description: Item updated successfully
          content:
            application/json:
              schema:
                $ref: '#/components/schemas/Item'
        '404':
          description: Item not found

components:
  schemas:
    Item:
      type: object
      properties:
        id:
          type: string
        name:
          type: string
        description:
          type: string
      required:
        - id
        - name
    NewItem:
      type: object
      properties:
        name:
          type: string
        description:
          type: string
      required:
        - name
    UpdateItem:
      type: object
      properties:
        name:
          type: string
        description:
          type: string
      required:
        - name

@Leon-Luu commented on GitHub (Feb 2, 2026): Adding a simple test openapi spec if anyone would like to test: ``` openapi: 3.0.3 info: title: Example API version: 1.0.0 description: An example API with multiple server environments and common HTTP methods. servers: - url: https://api.example.com/v1 description: Production server - url: https://staging-api.example.com/v1 description: Staging server - url: https://dev-api.example.com/v1 description: Development server paths: /items: get: summary: Get list of items responses: '200': description: A list of items. content: application/json: schema: type: array items: $ref: '#/components/schemas/Item' post: summary: Create a new item requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/NewItem' responses: '201': description: Item created successfully content: application/json: schema: $ref: '#/components/schemas/Item' /items/{itemId}: parameters: - in: path name: itemId required: true schema: type: string description: The ID of the item get: summary: Get an item by ID responses: '200': description: Item details content: application/json: schema: $ref: '#/components/schemas/Item' '404': description: Item not found put: summary: Update an item by ID requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/UpdateItem' responses: '200': description: Item updated successfully content: application/json: schema: $ref: '#/components/schemas/Item' '404': description: Item not found components: schemas: Item: type: object properties: id: type: string name: type: string description: type: string required: - id - name NewItem: type: object properties: name: type: string description: type: string required: - name UpdateItem: type: object properties: name: type: string description: type: string required: - name ```

kerem commented

2026-03-16 23:50:37 +03:00

Author

Owner

@ANKANJAGTAP commented on GitHub (Feb 3, 2026):

Hi
I’d like to work on this feature if it’s not already being handled.
Is the proposed approach (generating an environment/base URL variable from multiple OpenAPI servers) acceptable?
Happy to open a PR once aligned.

@ANKANJAGTAP commented on GitHub (Feb 3, 2026): Hi I’d like to work on this feature if it’s not already being handled. Is the proposed approach (generating an environment/base URL variable from multiple OpenAPI servers) acceptable? Happy to open a PR once aligned.

kerem commented

2026-03-16 23:50:42 +03:00

Author

Owner

@ameduza commented on GitHub (Feb 11, 2026):

Hi, I bumped into the similar issue during the product review from my side. In my case I don't have several servers defined in OpenApi spec. Instead, I have separate spec for every environment like dev/qa/uat...

When I import any spec with Postman it performs two useful update:

defines baseUrl variable on a collection level with the initial value form the spec. Normally I update it with the variable from my Globals, with the value depended on the selected environment DEV/QA/UAT...
Every request then have {{baseUrl}} prefix defined and leads to a correct environment

See the screen below with these steps. For my organization that is a real impediment for the migration from Postman as we have a number of APIs we are working on and import them from OpenApi specs from time to time. Switch between environments is crucial for us.

@ameduza commented on GitHub (Feb 11, 2026): Hi, I bumped into the similar issue during the product review from my side. In my case I don't have several servers defined in OpenApi spec. Instead, I have separate spec for every environment like dev/qa/uat... When I import any spec with Postman it performs two useful update: 1. defines `baseUrl` variable on a collection level with the initial value form the spec. Normally I update it with the variable from my Globals, with the value depended on the selected environment DEV/QA/UAT... 2. Every request then have {{baseUrl}} prefix defined and leads to a correct environment See the screen below with these steps. For my organization that is a real impediment for the migration from Postman as we have a number of APIs we are working on and import them from OpenApi specs from time to time. Switch between environments is crucial for us. <img width="937" height="432" alt="Image" src="https://github.com/user-attachments/assets/db070184-8b25-47b4-a9bd-720a6c3f0809" />

kerem commented

2026-03-16 23:50:47 +03:00

Author

Owner

@ReK42 commented on GitHub (Feb 11, 2026):

For a practical example, look at the OpenAPI spec files for Matrix in openapi-artifact.zip: https://github.com/matrix-org/matrix-spec/releases/latest

For example, the client/server API spec is:

{
    "components": {...},
    "info": {
        "title": "Matrix Client-Server API",
        "version": "v1.17"
    },
    "openapi": "3.1.0",
    "paths": {...},
    "servers": [
        {
            "url": "https://matrix.org"
        },
        {
            "url": "https://{homeserver_address}",
            "variables": {
                "homeserver_address": {
                    "default": "matrix-client.matrix.org",
                    "description": "The base URL for your homeserver"
                }
            }
        }
    ]
}

When importing to Hoppscotch as-is, only the first server URL of https://matrix.org is available.

Additionally, if I delete that first server entry so it imports the second entry, {homeserver_address} is not recognized as a variable and used as a literal string. This results in all paths being, for example, the static string https://{homeserver_address}/.well-known/matrix/client

@ReK42 commented on GitHub (Feb 11, 2026): For a practical example, look at the OpenAPI spec files for Matrix in `openapi-artifact.zip`: https://github.com/matrix-org/matrix-spec/releases/latest For example, the client/server API spec is: ```json { "components": {...}, "info": { "title": "Matrix Client-Server API", "version": "v1.17" }, "openapi": "3.1.0", "paths": {...}, "servers": [ { "url": "https://matrix.org" }, { "url": "https://{homeserver_address}", "variables": { "homeserver_address": { "default": "matrix-client.matrix.org", "description": "The base URL for your homeserver" } } } ] } ``` When importing to Hoppscotch as-is, only the first server URL of `https://matrix.org` is available. Additionally, if I delete that first server entry so it imports the second entry, `{homeserver_address}` is not recognized as a variable and used as a literal string. This results in all paths being, for example, the static string `https://{homeserver_address}/.well-known/matrix/client`

kerem referenced this issue

2026-03-17 01:17:40 +03:00

[PR #2282] [CLOSED] chore(deps): bump @codemirror/lint from 0.19.6 to 0.20.1 #3703