Skip to documentation

Workspace · Authentication

Available

Separate control-plane access from mocked authentication

A DotMock management credential authorizes changes to your team. A published mock may separately require a valid team x-api-key, and an endpoint can still model whatever Authorization behavior the real provider expects.

In this guide

  • Choose the correct credential for each surface
  • Protect a published mock URL
  • Test missing and invalid credentials
  • Keep secrets out of definitions and repositories

Prerequisites

  • A DotMock workspace you can access
  • The API ID in $API_ID and its published runtime URL in $MOCK_URL when the example calls the mock
On this page
  1. Know which system is authenticating
  2. Require a team API key on the mock
  3. Model the authentication contract your client expects
  4. Keep credentials out of mock content

Know which system is authenticating

Dashboard sessions and team API keys protect management operations such as reading definitions, changing state, or publishing. The mock runtime can independently require x-api-key for incoming client requests. Request conditions can model provider-specific Bearer, Basic, signature, or custom-header behavior without granting management access.

Require a team API key on the mock

Open API settings and enable the x-api-key requirement. Requests without the header receive 401; a key rejected for that team or API receives 403. The built-in tester and generated curl examples show the header when protection is enabled.

bash
curl "$DOTMOCK_API_URL/users" \
  -H "x-api-key: $DOTMOCK_API_KEY"

Model the authentication contract your client expects

If the real API expects Authorization: Bearer, a signature header, or a tenant key, add request-header conditions and provider-shaped 401 or 403 bodies. This tests client error handling without exposing a live credential.

Missing bearer token
!("authorization" in header)

Keep credentials out of mock content

Inject keys through a password manager, shell environment, CI secret store, or MCP secure input. Do not place a live token in a response template, captured traffic fixture, screenshot, or checked-in curl command.

  • Use separate keys for local development, CI, and agents
  • Grant the minimum API permissions each key needs
  • Rotate and revoke keys when a workflow changes
  • Review captured headers before promoting traffic