APIs & Endpoints

Learn how to structure your mock APIs and create powerful endpoints with dotMock.

API Structure

Understanding how dotMock organizes your mock APIs

API Project

Top-level container for your mock API with its own unique subdomain

https://my-ecommerce-api.mock.rest

Endpoints

Individual routes that respond to HTTP requests with dynamic responses

GET
/api/products
POST
/api/users/login
PUT
/api/orders/{orderId}

Response Rules

Conditional responses based on request attributes and dynamic templates

{ "id": "{{uuid}}", "name": "{{randomName}}", "status": "{{randomChoice('active', 'inactive')}}" }

Creating an API

Step-by-step guide to setting up your mock API

Getting Started

To create a new API in dotMock, navigate to your dashboard and click the "New API" button. This will open the API creation form where you can configure your mock API settings.

Required Fields

API Name

The API name is used to generate your unique subdomain. It must be:

  • Lowercase letters only
  • Numbers allowed
  • Hyphens allowed (but not at start or end)
  • 3-63 characters long
  • Unique across all dotMock APIs

Example transformations:

my-ecommerce-api → https://my-ecommerce-api.mock.restuser-service → https://user-service.mock.rest

Description

Optional field to help you and your team understand what this API is for. This description is only visible in your dashboard and doesn't affect the API functionality.

Adding Endpoints

Configure individual routes and their responses

Overview

After creating your API, you can add endpoints by clicking the "Add Endpoint" button in your API dashboard. Each endpoint represents a specific route that will respond to HTTP requests.

HTTP Methods

dotMock supports all standard HTTP methods. Click on any method to see detailed usage information:

GET
Retrieve data from the server
When to use:

Use GET requests to fetch data without modifying server state. GET requests should be safe and idempotent.

Common use cases:

Fetching user profiles, product listings, or configuration data

GET /api/users - List all users
GET /api/users/123 - Get specific user
GET /api/products?category=electronics - Filtered product list
Example request/response:
// GET requests typically don't have a request body
// Response example:
{
  "users": [
    {
      "id": "{{uuid}}",
      "name": "{{randomName}}",
      "email": "{{randomEmail}}",
      "profile": {
        "avatar": "https://example.com/{{randomInt(1,1000)}}.jpg",
        "joinedAt": "{{date('-1y')}}"
      }
    }
  ],
  "pagination": {
    "page": 1,
    "total": 150
  }
}

Path Configuration

Define the URL path for your endpoint. dotMock supports both static paths and dynamic path parameters.

Static Paths

Static paths match exactly and are ideal for collection endpoints:

/api/users/api/products/health

Dynamic Path Parameters

Use curly braces {} to define path parameters that can match any value:

/api/users/{userId}/api/products/{productId}/api/orders/{orderId}/items/{itemId}

Path parameters can be referenced in your response templates using the same name.

Response Configuration

Define how your endpoints respond to requests

Status Codes

Set the HTTP status code that your endpoint will return. Click on any status code to see detailed usage information:

Success (2xx)

Client Error (4xx)

Server Error (5xx)

200OK

Request successful

When to use:

Use for successful GET requests, successful updates, or any successful operation that returns data.

Example scenario:

GET /api/users returns a list of users

Example response payload:
{
  "users": [
    {
      "id": "{{uuid}}",
      "name": "{{randomName}}",
      "email": "{{randomEmail}}",
      "status": "active"
    }
  ],
  "total": 1
}

Response Headers

Configure custom headers that will be included in the response. Common headers include:

Content-Type:application/json
Cache-Control:no-cache
X-API-Version:1.0
X-Request-ID:{{uuid}}

Response Body Templates

Define the JSON response body using Go template syntax. You can use path parameters, query parameters, and dynamic template functions to create realistic responses.

Example: User Profile Response

{
  "id": "123",
  "name": "{{randomName}}",
  "email": "{{randomEmail}}",
  "avatar": "https://avatars.example.com/{{randomInt(1, 1000)}}.jpg",
  "isActive": {{randomBool}},
  "createdAt": "{{date('-1y')}}",
  "lastLogin": "{{date('-1d')}}"
}

Example: Product List Response

{
  "products": [
    {
      "id": "{{uuid}}",
      "name": "{{randomChoice('Widget', 'Gadget', 'Tool', 'Device')}}",
      "price": {{randomFloat(10, 999)}},
      "inStock": {{randomBool}},
      "category": "{{randomChoice('electronics', 'tools', 'home')}}"
    },
    {
      "id": "{{uuid}}",
      "name": "{{randomChoice('Widget', 'Gadget', 'Tool', 'Device')}}",
      "price": {{randomFloat(10, 999)}},
      "inStock": {{randomBool}},
      "category": "{{randomChoice('electronics', 'tools', 'home')}}"
    },
    {
      "id": "{{uuid}}",
      "name": "{{randomChoice('Widget', 'Gadget', 'Tool', 'Device')}}",
      "price": {{randomFloat(10, 999)}},
      "inStock": {{randomBool}},
      "category": "{{randomChoice('electronics', 'tools', 'home')}}"
    }
  ],
  "total": 3,
  "page": 1
}

Testing Your Endpoints

How to test and verify your mock API responses

Overview

Once your API and endpoints are configured, you can test them using any HTTP client. Your mock API is immediately available at your unique subdomain and will respond with the configured data.

Testing Your API

Test your endpoints using cURL, Postman, Insomnia, or directly in your application code:

Example cURL Request

curl -X GET https://my-api.mock.rest/api/users \
  -H "Content-Type: application/json"

JavaScript Example

const response = await fetch('https://my-api.mock.rest/api/users');
const users = await response.json();

Response Verification

When testing your endpoints, verify that:

Response status code matches your configuration
Response headers are included as expected
Dynamic template functions generate realistic data
Path parameters are correctly substituted in responses
Response structure matches your template

Best Practices

Use RESTful conventions for endpoint paths and methods

Group related endpoints with consistent naming

Document each endpoint with clear descriptions

Use response templates for consistency

Test edge cases with response rules