RequestBiteEnvironments
Environments let you attach authentication and encrypted secrets to one or more collections. When a collection is linked to an environment, Slingshot automatically applies the environment's auth configuration and makes its secrets available as variables in all requests within that collection.
Because environments often hold sensitive credentials, all secret values and authentication configuration are stored encrypted in your browser using a password you set the first time you visit the Environments page.
Encryption key setup
The first time you open the Environments page without an active session key, you are prompted to set a password. This password derives the encryption key used to protect all your environment secrets and auth config. It must be at least 4 characters long. You will be asked for this password every time you load Slingshot with active environments.
Forgot your password?
If you forget your password you can choose to clear all environments from the login prompt. This is irreversible, but lets you start fresh.
The Environments list
The Environments list is found at https://s.requestbite.com/environments. It shows all your environments in a table with the following columns:
| Column | Description |
|---|---|
| Name | The environment name. Click it to open the environment editor. |
| Collections | The number of collections linked to this environment. |
| Secrets | The number of encrypted secrets stored in the environment. |
| Auth | The configured authentication method. |
The ⋯ options menu on each row offers:
- Edit — open the environment editor (same as clicking the name).
- Delete — permanently remove the environment.
The ⋯ button in the top-right corner of the page provides:
- Export — export all environments to a file.
- Import — import environments from a previously exported file.
A new environment can be created by clicking Add Environment.
The environment editor
Clicking an environment name opens the environments editor. The editor is split into three sections, accessible from the sidebar on the left (or from a slide-out drawer on small screens): General, Secrets, and Auth.
General
- Name (required) — a human-readable label for the environment.
- Description (optional) — free-form notes.
Save persists the name and description and returns you to the list. Cancel discards unsaved changes (with a confirmation prompt if changes exist). Delete permanently removes the environment.
Secrets
Secrets are encrypted key-value pairs that can be referenced inside requests using the syntax, the same way collection variables work. Secret values are stored encrypted and are masked (shown as bullet characters) in the UI.
Adding a secret
Fill in the Key and Value fields and click Add. The new secret appears in the table immediately (highlighted) but is not persisted until you click Save.
Editing a secret
Click the edit (pencil) icon on a secret row to open the edit modal. Update the key and/or value and click Save in the modal.
Deleting a secret
Click the delete (trash) icon on a secret row. A confirmation dialog appears before the secret is removed.
Click Save to persist all pending secret changes, or Cancel to discard them (with a confirmation prompt if there are unsaved changes).
Auth
The Auth section lets you configure how Slingshot authenticates requests made within collections linked to this environment. Select an authentication type from the dropdown; Slingshot then injects the credentials automatically into every request.
The following authentication types are supported:
No auth
No authentication is added. This is the default.
API Key
Adds a single key/value pair to every request, either as a header or as a query parameter.
| Field | Required | Description |
|---|---|---|
| Key | Yes | The parameter name (e.g. X-API-Key, api_key). |
| Value | Yes | The API key value. Stored encrypted. |
| Add to | — | Where to inject the key: Header (default) or Query Params. |
Basic Auth
Sends HTTP Basic Authentication credentials with every request.
| Field | Required | Description |
|---|---|---|
| Username | — | The username. |
| Password | — | The password. Stored encrypted. |
Bearer Token
Adds an Authorization: Bearer <token> header to every request.
| Field | Required | Description |
|---|---|---|
| Token | Yes | The bearer token value. Stored encrypted. |
OAuth 2.0 (PKCE)
Implements the OAuth 2.0 Authorization Code flow with PKCE (Proof Key for Code Exchange). Suitable for public clients that do not use a client secret. The authorization happens in a browser popup; Slingshot then stores and automatically uses the resulting access token.
| Field | Required | Description |
|---|---|---|
| Authorization URL | Yes | The provider's authorization endpoint. |
| Token URL | Yes | The provider's token endpoint. |
| Client ID | Yes | Your application's client ID. |
| Client Secret | — | Leave empty for pure public clients; some providers require it even with PKCE. |
| Redirect URI | Yes | Must match what is registered in your OAuth app. Defaults to <origin>/auth/callback. |
| Scope | Yes | Space-separated list of requested scopes. |
| State | — | Optional CSRF-protection state value; auto-generated if left empty. |
| Code Challenge Method | Yes | SHA-256 (recommended) or plain. |
| Refresh Token URL | — | Token refresh endpoint; defaults to the Token URL if not set. |
| Token Request headers | — | Custom headers to include when making token requests to the provider. |
Actions
- Save Configuration — saves the fields without triggering a browser login.
- Get Tokens — opens a popup to authenticate with the provider and retrieve access and refresh tokens.
- Refresh Tokens — available when a refresh token is stored; exchanges it for a new access token without user interaction.
- Clear Tokens — removes the stored access and refresh tokens.
OAuth 2.0 (Code Flow)
Implements the standard OAuth 2.0 Authorization Code flow for confidential clients that have a client secret. The token exchange is routed through the configured proxy so that the client secret is not exposed in the browser.
Proxy required
The client secret is sent through the proxy during the code-for-token exchange. Make sure your proxy is configured and trusted before using this flow.
| Field | Required | Description |
|---|---|---|
| Authorization URL | Yes | The provider's authorization endpoint. |
| Token URL | Yes | The provider's token endpoint. |
| Client ID | Yes | Your application's client ID. |
| Client Secret | Yes | Your application's client secret. Sent via the proxy. |
| Redirect URI | Yes | Must match what is registered in your OAuth app. Defaults to <origin>/auth/callback. |
| Scope | — | Space-separated list of requested scopes (optional). |
| State | — | Optional CSRF-protection state value; auto-generated if left empty. |
| Token Request headers | — | Custom headers to include when making token requests. |
Actions are the same as for OAuth 2.0 (PKCE): Save Configuration, Get Tokens, Refresh Tokens, and Clear Tokens.
OpenID Connect (PKCE)
Implements OpenID Connect using PKCE, discovered automatically from the provider's well-known metadata endpoint. Designed for OIDC-compliant providers such as Google, Auth0, Okta, and others.
| Field | Required | Description |
|---|---|---|
| Domain | Yes | The OIDC provider domain, with or without https:// (e.g. auth.example.com). Used to discover the well-known configuration. |
| Client ID | Yes | Your application's client ID. |
| Client Secret | — | Required by some providers (e.g. Google) even when using PKCE. Leave empty for providers that support pure public clients. |
| Scopes | Yes | Space-separated list of requested scopes. Defaults to openid profile email. |
Actions are the same as for the other OAuth flows: Save Configuration, Get Tokens, Refresh Tokens, and Clear Tokens.
The authentication response (access token, refresh token, ID token, expiry, and profile) is displayed as read-only JSON beneath the action buttons once tokens have been obtained. When an active access token is stored, Slingshot automatically includes it as the Authorization header in requests that use this environment.