[feature]: Unified HTTP & WebSocket Collections with Multiple Concurrent WebSocket Sessions

Is there an existing issue for this?

• I have searched the existing issues

Summary

Feature Request: Unified HTTP & WebSocket Collections with Multiple Concurrent WebSocket Sessions

Description

Currently, HTTP requests and WebSocket connections in Hoppscotch are handled as separate workflows.

This becomes inconvenient when working on applications that use both HTTP APIs and WebSockets as part of the same project.

For example, a real-time messaging application might use:

• HTTP for authentication, fetching conversations, message history, file uploads, etc.
• WebSocket for real-time messages, delivery/read events, presence, typing indicators, etc.

Ideally, these requests should be manageable together as part of the same project/collection.

There are two related improvements that would make the WebSocket workflow significantly more useful.

1. Allow WebSocket requests to be saved in collections

WebSocket requests should be saveable alongside HTTP requests inside the same collection/project.

For example:

Chat API
├── Auth
│   ├── POST /login
│   └── POST /refresh
│
├── Conversations
│   ├── GET /conversations
│   └── GET /conversations/:id/messages
│
└── Realtime
    ├── WS Main Connection
    ├── WS User A
    └── WS User B

A saved WebSocket request could preserve things such as:

• WebSocket URL
• Query parameters
• Headers
• Authentication configuration
• Protocols/subprotocols
• Environment variables
• Saved messages/events that can be sent after connecting

This would make WebSocket endpoints first-class members of a project's API collection rather than a separate temporary workflow.

2. Support multiple concurrent WebSocket sessions

It would also be very useful to allow multiple WebSocket connections to remain open simultaneously.

Currently, testing scenarios involving multiple connected clients is difficult.

For example, when developing a chat application, I may want to have:

WebSocket #1 → User A
WebSocket #2 → User B
WebSocket #3 → User C

all connected at the same time.

Then I could send a message from User A and immediately inspect what User B and User C receive.

This is useful for testing many real-time systems, including:

• Chat applications
• Notifications
• Presence systems
• Collaborative applications
• Multiplayer systems
• Pub/Sub systems
• Event-driven APIs

A tab-based WebSocket interface could potentially work well for this:

[ User A ● ] [ User B ● ] [ User C ● ] [ + ]

Each tab would have its own independent:

• Connection state
• Authentication/headers
• Message history
• Message composer
• WebSocket URL

Closing or disconnecting one session should not affect the others.

Expected behavior

Ideally, Hoppscotch would allow users to:

1. Save WebSocket requests.
2. Organize HTTP and WebSocket requests inside the same collections/folders.
3. Open saved WebSocket requests from a collection.
4. Keep multiple WebSocket connections open simultaneously.
5. Switch between active WebSocket sessions without disconnecting them.
6. Use different authentication/headers/environment variables for each connection.

Why should this be worked on?

Modern applications often don't use HTTP or WebSocket exclusively — they use both.

Treating WebSocket connections similarly to HTTP requests from an organizational perspective would make Hoppscotch much more convenient for developing and debugging real-time applications.

Multiple simultaneous WebSocket sessions would also make it possible to test real-world multi-client scenarios without opening multiple browser windows, Hoppscotch instances, or using additional tools.