Authentication overview

Mocky provides a service for creating mock HTTP endpoints, primarily used for rapid prototyping, frontend development, and API testing without requiring a live backend. For basic usage, creating a public mock endpoint does not necessitate authentication. Users can define custom HTTP responses, headers, and status codes directly through the Mocky web interface without logging in. These unauthenticated mocks are assigned a unique URL and are accessible to anyone with the link.

However, to manage personal mocks, access premium features, or ensure that only authorized accounts can modify created mocks, Mocky employs an API Key-based authentication system. This key identifies the user and grants access to account-specific functionalities, such as viewing and editing private mocks or utilizing features available to Mocky Premium subscribers. The API Key serves as the primary mechanism for authenticating programmatic interactions with the Mocky platform and securing user-specific configurations.

Supported authentication methods

Mocky's authentication strategy focuses on simplicity and direct access control, primarily utilizing a personal API Key. This method is suitable for individual developers and small teams managing their mock endpoints. The service prioritizes ease of use for quick mock creation without an account, while offering API Key authentication for managing persistent and private mocks.

Method When to Use Security Level Description
API Key (Bearer Token) For programmatic access to your Mocky account, managing private mocks, and using premium features. Moderate The API Key is sent in the Authorization header as a Bearer token, e.g., Authorization: Bearer YOUR_API_KEY. This is the recommended method for secure API interactions with your Mocky account.
API Key (Query Parameter) Not recommended for sensitive operations in production. Potentially useful for quick, non-sensitive testing or scripts where security exposure is minimal. Low The API Key is appended to the URL as a query parameter, e.g., ?apiKey=YOUR_API_KEY. This method exposes the key in logs and browser history, reducing its security.
No Authentication For creating public, temporary mock endpoints that do not require account management or advanced features. Ideal for quick sharing and anonymous testing. N/A (public access) Mocks created without authentication are publicly accessible and cannot be managed via an API key, only through their unique URL.

While API Keys offer a straightforward approach to authentication, developers should be aware of their limitations compared to more robust methods like OAuth 2.0. API Keys are typically long-lived credentials and do not inherently include features like token refreshing or scoped permissions beyond what the associated user account can do. For information on general API key security, refer to the Microsoft Azure API Management documentation on API keys.

Getting your credentials

To obtain your Mocky API Key, you need to register for a Mocky account. Once registered and logged in, your API Key is typically available in your user dashboard or profile settings. The process generally involves these steps:

  1. Register for an Account: Navigate to the Mocky homepage and sign up for a free account.
  2. Log In: After registration, log in to your newly created Mocky account.
  3. Access Dashboard/Profile: Within your user interface, look for a section labeled "Dashboard," "Profile," "Account Settings," or similar. Your API Key is usually prominently displayed or can be generated from within this section.
  4. Generate/Copy API Key: If an API Key is not immediately visible, there might be an option to generate a new one. Once generated, copy this key. It is a long alphanumeric string that uniquely identifies your account for programmatic access.

Mocky's official documentation provides the most precise instructions for locating and managing your API Key. It is crucial to treat this key as sensitive information, similar to a password, as it grants full access to your Mocky account's managed mocks and premium features.

Authenticated request example

When interacting with Mocky programmatically to manage your mocks (e.g., creating, updating, or deleting private mocks via an API), your API Key must be included in the request. The recommended and most secure method is to send it in the Authorization header as a Bearer token.

Creating a Mock (using curl)

This example demonstrates how to create a mock endpoint programmatically using curl, authenticating with your API Key in the Authorization: Bearer header. Replace YOUR_API_KEY with your actual Mocky API Key and adjust the JSON payload as needed for your desired mock response.


curl -X POST \
  https://www.mocky.io/api/mock \
  -H 'Content-Type: application/json' \
  -H 'Authorization: Bearer YOUR_API_KEY' \
  -d '{ 
    "response": {
      "status": 200, 
      "headers": {
        "Content-Type": "application/json"
      },
      "body": {"message": "Hello from authenticated mock!"}
    },
    "private": true, 
    "expiration": "1h" 
  }'

In this request:

  • -X POST specifies the HTTP POST method.
  • https://www.mocky.io/api/mock is the Mocky API endpoint for creating new mocks.
  • -H 'Content-Type: application/json' indicates that the request body is JSON.
  • -H 'Authorization: Bearer YOUR_API_KEY' sends your API Key securely.
  • -d contains the JSON payload defining the mock's response, including a private: true flag to make it an authenticated mock visible only to your account.

Upon successful execution, the API will return a response containing the URL of your newly created authenticated mock. You can then access or manage this mock through your Mocky dashboard or further API calls, provided you continue to authenticate with your API Key.

Security best practices

Protecting your Mocky API Key is essential to maintain the integrity and privacy of your mock endpoints. Adhering to security best practices helps prevent unauthorized access and potential misuse of your account.

  • Treat API Keys like Passwords: Your Mocky API Key grants access to your account and associated mocks. Never embed API keys directly in client-side code (e.g., JavaScript in a browser), public repositories, or commit them to version control systems without proper security measures like environment variables or secret management tools. For server-side applications, use environment variables to store and access keys.
  • Use Environment Variables: Store API Keys as environment variables on your server or development machine. This practice keeps keys out of your codebase and makes them easy to manage and rotate without code changes. For instance, in a Linux/macOS environment, you might use export MOCKY_API_KEY="YOUR_API_KEY".
  • HTTPS Only: Always use HTTPS when making API calls to Mocky. HTTPS encrypts the communication channel, protecting your API Key from interception during transit. Mocky endpoints naturally use HTTPS, but always confirm the protocol in your requests.
  • Avoid Query Parameters for Keys: Do not pass your API Key as a query parameter in the URL (e.g., ?apiKey=YOUR_API_KEY). This exposes the key in server logs, browser history, and potentially HTTP referrers, making it vulnerable to exposure. The IETF RFC 6750 for Bearer Token usage recommends against this for sensitive information.
  • Regular Key Rotation: Periodically rotate your API Key. If Mocky provides functionality to generate new keys and invalidate old ones, utilize it. This minimizes the risk associated with a compromised key over its lifetime.
  • Restrict Access: Limit who has access to your API Key. Only grant access to developers or systems that absolutely require it.
  • Monitor Usage: If Mocky provides usage logs or monitoring features, regularly review them for any unusual activity that might indicate a compromised key.
  • Secure Development Environment: Ensure that your development machines and build pipelines are secure. Malware or unsecured environments can expose API Keys stored locally.
  • Error Handling: Implement robust error handling in your applications. Avoid logging API Keys or sensitive information in error messages or publicly accessible logs. Mask or redact sensitive data before logging.