mirror of
https://github.com/hoppscotch/hoppscotch.git
synced 2026-04-26 09:16:03 +03:00
[GH-ISSUE #5477] [feature]: Support for Parent Collection-Level Scripts #2102
Labels
No labels
CodeDay
a11y
browser limited
bug
bug fix
cli
core
critical
design
desktop
discussion
docker
documentation
duplicate
enterprise
feature
feature
fosshack
future
good first issue
hacktoberfest
help wanted
i18n
invalid
major
minor
need information
need testing
not applicable to hoppscotch
not reproducible
pull-request
question
refactor
resolved
sandbox
self-host
spam
stale
testmu
wip
wont fix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/hoppscotch#2102
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @Leon-Luu on GitHub (Oct 10, 2025).
Original GitHub issue: https://github.com/hoppscotch/hoppscotch/issues/5477
Is there an existing issue for this?
Summary
Summary:
Currently, Hoppscotch does not support the ability to create and manage scripts at the parent collection level. This feature is available in tools like Postman and is highly valuable for managing complex API testing workflows. We would like to request the addition of parent collection-level scripting capabilities in Hoppscotch.
Description:
In many API testing scenarios, it is crucial to define scripts that apply to all requests or child collections within a parent collection. This enables users to centralize logic, reduce duplication, and streamline test maintenance. However, Hoppscotch currently restricts scripting to the individual request or environment level, which leads to repetitive code and increased management overhead.
Why should this be worked on?
Centralized Environment Setup:
Ability to generate or modify environment variables (such as tokens, URLs, or configuration values) that automatically propagate to all child collections and requests. This is useful for setting up authentication, base URLs, or other shared context.
Chained Requests for Shared Data:
Support for chaining requests at the parent collection level to fetch tokens, session data, or payloads that are needed by multiple requests within the collection. For example, retrieving an OAuth token once and using it across all child requests.
Reusable and Common Scripts:
Define common pre-request or test scripts (e.g., logging, validation, error handling) that should run for every request in the collection, ensuring consistency and reducing duplication.
@GuryYu commented on GitHub (Nov 13, 2025):
very useful feature