Learn how to structure and manage your API projects effectively
A project is a container for related API endpoints. Think of it as a complete API service with its own base URL, data schema, and set of endpoints. Each project represents a distinct API that you're mocking or prototyping.
User Management API - User CRUD, authentication, profiles
E-commerce Product API - Products, categories, inventory
Blog Content API - Posts, authors, comments, tags
Task Management API - Tasks, projects, assignments
New to the platform? Learn more about Guest Mode and how to convert your temporary work into a permanent project.
Each project has several key properties that define its behavior:
A human-readable identifier for your project (e.g., "User Management API")
Must be 3-50 characters
Should be descriptive and clear
Can be changed later in project settings
A URL-friendly version of your project name (e.g., "user-management-api")
Auto-generated from project name
Used in API URLs: /api/your-slug
Must be unique across your projects
Cannot be changed after creation
The root path for all endpoints in this project (e.g., "/api/v1")
Default: /api/[slug]
Can be customized to match your API design
All endpoints inherit this base path
Example:
Base URL: /api/users
Full endpoint: https://www.mockapibuilder.io/api/users
Optional documentation about the project's purpose
Up to 500 characters
Helps team members understand the project
Searchable from the dashboard
Understanding how projects are organized helps you build better APIs:
Important: Each HTTP method (GET, POST, PUT, DELETE) is stored as a separate endpoint in the database. When you create a resource like "users", the system automatically generates 5 individual endpoints that you can configure independently.
When to use:
Related resources (users, posts, comments)
Same data domain
Shared authentication
Consistent base URL
Example: Blog API with posts, authors, and comments
When to use:
Different business domains
Separate services/microservices
Different versions (v1, v2)
Independent deployment
Example: User API, Product API, and Order API as separate projects
Create from scratch, use a template, or import from OpenAPI spec
Add endpoints via Settings, customize responses, test with API tester
Tip: Click the Settings button on your project page and go to the General tab to add new endpoints anytime.
Use in frontend apps, share with team, monitor request logs
Generate documentation, export to Postman, transition to production API
Remove when no longer needed (permanent deletion)
Good: "E-commerce Product Catalog API"
Bad: "Project 1", "Test API"
Include purpose, scope, and any important notes. This helps team members and your future self.
• Use lowercase for slugs: user-api
• Be consistent with versioning: /api/v1
• Use hyphens, not underscores: product-catalog
Delete or archive projects you're no longer using to keep your dashboard organized and improve performance.
Create separate projects for each microservice:
/api/users/api/products/api/orders/api/paymentsMaintain multiple versions simultaneously:
/api/v1/users/api/v2/usersCreate separate projects for testing new features: