Authentication

The Auth tab attaches credentials to a request without forcing you to write the Authorization header yourself. There are five modes; pick the one that matches what the API expects.

No auth

Default. Sends no Authorization header. Use this for public endpoints.

Bearer token

Pastes a token into the Authorization: Bearer … header at send time. Type or paste the token into the Token field.

Authorization: Bearer <your token>

You can put a {{variable}} here, and the token will be resolved from the active environment.

Basic auth

A username and password are joined with :, base64-encoded, and sent as Authorization: Basic ….

Type the username in the first field and the password in the second. The password input masks the value. Both support variables.

Authorization: Basic <base64(username:password)>

API key

A key/value pair that is added either as a header or as a query parameter.

• Add to — choose In header or In query.
• Key name — the header name (e.g. X-API-Key) or the query parameter name.
• Key value — the secret value.

Both fields support {{variable}} substitution.

OAuth 2.0

Three grant types are supported, picked from the Grant type dropdown.

Client credentials

Rewind handles the token exchange for you. Fill in:

• Token URL — the OAuth 2 token endpoint, e.g. https://auth.example.com/oauth/token.
• Client ID and Client secret — your application's credentials.
• Scope — optional, space-separated scopes.

When the request is sent, Rewind POSTs to the token URL with grant_type=client_credentials and an HTTP Basic auth header containing the client credentials, then injects the returned access_token as a Bearer token. Tokens are cached in memory for the lifetime of the dev server, keyed by tokenUrl + clientId + scope.

Authorization code / PKCE

Note — the browser-hosted build does not yet ship the embedded PKCE callback flow. The Authorization code grant type is available in the UI; the actual code/PKCE exchange must be done out of band, after which you paste the resulting access token into the Access token field.

If you already have a token from another tool, pick Authorization code / PKCE, paste the token into Access token, and the request will use it as a Bearer token. The PKCE flow itself is on the roadmap.

Manual access token

Same as Authorization code, but with no note about the callback. Use this if you have an access token from any source and just want to send it as a Bearer token.

Paste the token into the Access token field. The field masks the value by default. The token is sent as Authorization: Bearer <token>.

How secrets are handled

Anything you put in a Bearer token, Basic password, API key value, OAuth client secret, or OAuth access token field is masked in:

• the saved request (in the Authorization header value and in stored bodies),
• the local history,
• normal workspace exports (the export endpoint and the .rewind archive without the includeSecrets flag).

Variables resolve before masking. If a field's value is {{myToken}}, the request stores the literal {{myToken}} (not the resolved value) and the masked value when the request is sent. This keeps the secret in the environment, not the request.

What's next?

• Request settings — timeouts and redirects
• Environments — store credentials outside your requests
• Code generation — generate equivalent client code for any of these modes