Projects & Organization
Learn how to structure and manage your API projects effectively
What is a Project?
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.
Example Projects
- 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
Project Properties
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: http://localhost:3000/api/users
Optional documentation about the project's purpose
• Up to 500 characters
• Helps team members understand the project
• Searchable from the dashboard
Project Structure
Understanding how projects are organized helps you build better APIs:
One Project vs. Multiple Projects
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
Project Lifecycle
Creation
Create from scratch, use a template, or import from OpenAPI spec
Development
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.
Testing
Use in frontend apps, share with team, monitor request logs
Deployment
Generate documentation, export to Postman, transition to production API
Delete
Remove when no longer needed (permanent deletion)
Best Practices
✓ 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.
Common Patterns
Microservices Architecture
Create separate projects for each microservice:
- • User Service →
/api/users - • Product Service →
/api/products - • Order Service →
/api/orders - • Payment Service →
/api/payments
API Versioning
Maintain multiple versions simultaneously:
- • Project: "User API v1" →
/api/v1/users - • Project: "User API v2" →
/api/v2/users
Feature Testing
Create separate projects for testing new features:
- • Production API (stable)
- • Staging API (pre-release)
- • Experimental API (new features)