RequestRocket Documentation
Guides

Credentials

Learn about proxy and target credentials, how to create and manage them

Credentials

RequestRocket has two types of credentials that work together to secure your API traffic.

Understanding Credential Types

Proxy Credentials

Proxy credentials are used by your application to authenticate with RequestRocket's proxy service. These credentials ensure that only authorized applications can access your proxy endpoints.

When you create a proxy, you'll need to associate it with a proxy credential. This determines how your application authenticates with RequestRocket.

Target Credentials

Target credentials are used by RequestRocket to authenticate with your target APIs or services. These credentials are securely stored and used when RequestRocket forwards requests to your target endpoints.

When RequestRocket makes requests to your target API, it uses the target credential to authenticate, so your target API sees properly authenticated requests.

Think of it this way: Proxy credentials protect RequestRocket from unauthorized access, while target credentials allow RequestRocket to access protected APIs on your behalf.

Important: Once created, credential secrets cannot be viewed or edited for security reasons. Make sure to save any necessary information before saving the credential.

Supported Authentication Types

We support the creation of credentials for the following authentication types.

API Key

Used for services that require an API key in headers.

Available for: Proxy and Target credentials

Example usage:

GET /api/resource HTTP/1.1
X-API-Key: your-api-key-here

Bearer Token

OAuth 2.0 bearer token authentication.

Available for: Proxy and Target credentials

Example usage:

GET /api/resource HTTP/1.1
Authorization: Bearer your-token-here

Optional prefix: You can configure an optional prefix (e.g., Bearer , Token , or custom prefix)

JWT (JSON Web Token)

Custom JWT authentication where you provide the token.

Available for: Proxy and Target credentials

Example usage:

GET /api/resource HTTP/1.1
Authorization: your-jwt-token-here

JWT Verify

Cryptographic JWT verification for inbound requests. RequestRocket verifies the JWT signature against public keys from a JWKS endpoint (or a shared secret for HS256), rather than comparing a static token string. Designed for AI agents and service identities issued short-lived credentials by SPIFFE/SPIRE, Auth0, Okta, Cognito, Azure AD, or any standard JWT issuer.

Available for: Proxy credentials only

Example usage:

GET /api/resource HTTP/1.1
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5...

How it works: On first use, RequestRocket fetches public keys from your JWKS endpoint and caches them on the credential record. Subsequent requests with the same token are approved from cache without cryptographic re-verification. When a new token is presented (e.g. after SPIRE rotation), full verification runs again.

Required fields:

  • algorithms — Signing algorithms to accept (e.g. ["RS256"], ["ES256"], ["HS256"])
  • issuer — Expected iss claim (e.g. spiffe://acmecorp.com)
  • audience — Expected aud claim (e.g. https://global.requestrocket.net)
  • subject — Expected sub claim; supports wildcard suffix (spiffe://acmecorp.com/agents/*)

Signing source (one of):

  • jwksUri — JWKS or SPIFFE trust bundle URL (for RS256/ES256)
  • sharedSecret — Shared secret string (for HS256)

Optional fields:

  • clockSkewSeconds — Tolerance for clock drift (default: 30)
  • jwksRefreshHint — Override JWKS cache TTL in seconds (default: derived from bundle or 3600)
  • failPolicy — Behaviour when JWKS endpoint is unreachable: fail-closed (default, safest) or fail-open (serve from stale cache)
  • requiredClaims — Additional claims to validate beyond sub/iss/aud

JWT Verify uses a two-tier cache: first a fast string comparison against the last verified token, then full cryptographic verification when the token changes. This minimises latency on the hot path while remaining secure.

Basic Auth

Username and password authentication using HTTP Basic Auth.

Available for: Proxy and Target credentials

Example usage:

GET /api/resource HTTP/1.1
Authorization: Basic base64(username:password)

OAuth2

Full OAuth2 authentication flow support.

Available for: Target credentials only

Supported flows:

  • Authorization Code
  • Client Credentials
  • (More flows in development)

For OAuth2 targets using the authorization_code flow, use this callback URL: https://api.requestrocket.com/webhooks/oauth2

Custom

Custom authentication with configurable headers.

Available for: Target credentials only

Use case: For APIs that require custom authentication headers or non-standard authentication patterns.

Configuration:

  • Additional headers
  • Additional query parameters
  • Additional body data

Custom Token

Dynamic token fetching from an authentication endpoint, with automatic token refresh and expiration management.

Available for: Target credentials only

Use case: For APIs that require you to fetch a token from a separate authentication endpoint before making requests. RequestRocket will automatically fetch, cache, and refresh the token as needed.

Configuration:

Token Request Configuration

Configure how to fetch the token:

  • Token URL: The endpoint to fetch the authentication token from
  • HTTP Method: GET or POST
  • Token Request Headers: Headers to include in the token request (JSON format)
  • Token Request Query Params: Query parameters for the token request (JSON format)
  • Token Request Body: Body data for POST requests (JSON format)

Token Extraction Configuration

Configure how to extract the token from the response:

  • Token Path: JSON path to the token (e.g., access_token or data.token)
  • Expiry Method: How the expiry is formatted:
    • expires_in - seconds from now
    • expires_in_ms - milliseconds from now
    • expires_at - Unix timestamp
    • expires_at_iso - ISO 8601 date string (coming soon)
  • Token Expiry Path: JSON path to the expiry value (optional)

Token Application Configuration

Configure how to apply the token to target API requests:

  • Key Name: Header or query parameter name (e.g., Authorization, api_key)
  • Add to Header or Query Param: Toggle between adding to headers or query parameters
  • Prefix: Optional prefix for the token value (e.g., Bearer for Bearer {token})

Additional Request Fields (Optional)

These fields will be appended to every target API request:

  • Additional Headers: Extra headers to add to target requests (JSON format)
  • Additional Query Params: Extra query params to add to target requests (JSON format)
  • Additional Body Data: Extra body data to add to target requests (POST/PUT/PATCH only, JSON format)

The test endpoint feature in the UI allows you to verify your token configuration and see the extracted token and expiry values before saving.

Testing Target Credentials

Before saving a target credential, you can send a live test request to verify it works correctly. The credential is applied to the request exactly as it would be when RequestRocket proxies real traffic — letting you catch configuration mistakes before they affect production.

Credential testing is available for API Key, Bearer, JWT, Basic Auth, Custom, and None credential types. OAuth2 uses its own interactive consent flow, and Custom Token has a dedicated token endpoint tester within its configuration form.

How to Test

When creating a new target credential, expand the Test Credential card that appears below the Secret section. Configure your test request and click Test Credential.

Choose a URL

Select how to specify the request URL:

Select Target — pick an existing target from the dropdown. The path field is pre-populated with that target's configured Test Path. You can edit the path for this test run without changing the saved value.

Full URL — enter a complete URL (including path) directly, without selecting a target. Useful for testing against a specific endpoint before a target has been created.

Configure the Request

  • HTTP Method: GET or POST
  • Additional Request Headers (optional): Extra headers to include alongside the credential headers, in JSON format
  • Additional Query Parameters (optional): Extra query params to append, in JSON format
  • Request Body (optional, POST only): JSON body to send with the request

The credential headers are always applied — you cannot override them via the additional fields. For example, if the credential sets Authorization, that value cannot be replaced by an additional header with the same key.

Run the Test

Click Test Credential. The status is shown inline:

  • A green check and HTTP status code indicate the request succeeded (2xx–3xx)
  • A red cross with status code indicates an error response from the target

Click View Response to inspect the full response headers and body.

What Gets Applied

The credential is converted to request headers and/or query parameters before the test request is sent:

Auth TypeApplied as
API Key (addToHeader: true)Header [key]: [prefix] [value]
API Key (addToHeader: false)Query parameter [key]=[value]
BearerAuthorization: [prefix] [token]
JWTAuthorization: [prefix] [token]
Basic AuthAuthorization: Basic [base64(user:pass)]
CustomadditionalHeaders and additionalQueryParams from the secret
NoneNo credential headers — request is unauthenticated

Any additionalHeaders and additionalQueryParams configured on the credential secret are also merged into the test request.

Important Notes

Regional Constraints

Credentials are constrained to the region in which they are created. If you need to deploy proxies in multiple regions, you'll need to create credentials in each region.

All components of a proxy must be in the same region: proxy credential, target credential, target, and proxy itself.

Credential Management

  • Viewing Secrets: Credentials secrets cannot be viewed after creation for security reasons
  • Editing: You can edit credential metadata (name, notes) but not the secret values
  • Deletion: Deleting a credential will also delete any associated proxy definitions since they are linked to the credential
  • Multiple Credentials: You can create multiple credentials of each type

If you want to delete a credential, but keep a proxy that is using it, replace the credential on the proxy before deleting the credential.

Security Features

All credential secrets are:

  • Encrypted using AES-256-GCM before storage
  • Never transmitted or logged in plaintext
  • Securely deleted when credentials are removed

Troubleshooting

Authentication Failures

Issue: Receiving proxy-access-denied in response headers

Solution: Verify that:

  1. You're using the correct proxy credential
  2. The credential format matches the expected auth type
  3. The credential hasn't been deleted or disabled

Target Authentication Failures

Issue: Receiving proxy-access-granted but still getting 401/403 errors

Solution: The issue is with the target credential:

  1. Use the Test Credential feature when creating a new credential to verify it works before saving
  2. Verify the target credential is configured correctly
  3. Check that the target API credentials haven't expired
  4. Ensure the target credential has necessary permissions

Next Steps

Targets

Define your API endpoints

Proxies

Combine credentials and targets

Rules

Set up access control

Credentials API

Programmatic management

Organisations

Learn how to create and manage organisations, invite team members, and configure billing

Targets

Learn how to create and manage API targets in RequestRocket

On this page

Credentials
Understanding Credential Types
Proxy Credentials
Target Credentials
Supported Authentication Types
API Key
Bearer Token
JWT (JSON Web Token)
JWT Verify
Basic Auth
OAuth2
Custom
Custom Token
Token Request Configuration
Token Extraction Configuration
Token Application Configuration
Additional Request Fields (Optional)
Testing Target Credentials
How to Test
Choose a URL
Configure the Request
Run the Test
What Gets Applied
Important Notes
Regional Constraints
Credential Management
Security Features
Troubleshooting
Authentication Failures
Target Authentication Failures
Next Steps