Create and configure REST API endpoints with full CRUD operations
An endpoint is a specific URL path combined with an HTTP method that responds to requests. In Mock API Builder, each endpoint represents a single operation (like "GET /api/users" or "POST /api/users").
GET https://www.mockapibuilder.io/api/users/123Method: GET (retrieve data)
Base URL: https://www.mockapibuilder.io
Path: /api/users/123
Resource ID: 123
In Mock API Builder, each endpoint is tied to one specific HTTP method. When you create a resource, the system automatically generates 5 separate endpoints:
/api/users- List all users/api/users- Create new user/api/users/:id- Get single user/api/users/:id- Update user/api/users/:id- Delete userEach endpoint can be configured independently with its own schema, validation rules, and mock data. You can delete unwanted methods if you only need specific operations.
Each HTTP method corresponds to a specific type of operation. When you create a resource in Mock API Builder, each method becomes its own independent endpoint:
Fetch data from the server (list all or get by ID)
GET /api/usersReturns all users
GET /api/users/123Returns user with ID 123
Create new resources on the server
POST /api/usersCreates a new user
Replace entire resource with new data
PUT /api/users/123Updates user 123 (all fields)
Update only specific fields of a resource
PATCH /api/users/123Updates only specified fields
Remove resources from the server
DELETE /api/users/123Deletes user with ID 123
You have multiple ways to create endpoints in Mock API Builder:
Add endpoints to an existing project through the Settings dialog
Steps:
Automatic Endpoint Generation: When you add an endpoint, the system creates 5 separate database records (one for each CRUD method). Each can be independently configured or deleted.
Start fresh with a new project and add endpoints during setup
Steps:
Use pre-built templates for common use cases
Available Templates:
Import from existing OpenAPI/Swagger specifications
Benefits:
The URL path for your resource (plural nouns recommended):
Good examples:
/api/users/api/products/api/blog-postsAvoid:
/api/user (use plural)/api/getUsers (don't include verb)/api/Users (use lowercase)Note: When you specify a path like /api/users, the system creates both collection endpoints (/api/users) and item endpoints (/api/users/:id) automatically.
Define what data your endpoint returns:
Automatically handled based on the operation:
Used to identify specific resources:
/api/users/:idExample: /api/users/123 retrieves user with ID 123
Used for filtering, sorting, and pagination:
Filtering:
/api/users?role=admin&status=activeSorting:
/api/products?sort=price&order=descPagination:
/api/posts?page=2&limit=20/api/users
/api/getUsers
/api/products
/api/product
Use the same naming patterns across all endpoints
Maximum 2-3 levels deep for readability