Frequently Asked Questions

Yes, you need to create a free account to use Mock API Builder. This allows you to:

• Save and manage your projects
• Access your API endpoints from anywhere
• Use advanced features like authentication and rate limiting
• Track usage and monitor API logs

Sign up is quick and free - just provide your email and create a password.

Creating your first API is easy:

1. Log in to your account and go to the Dashboard
2. Click the "Create Project" button
3. Give your project a name and description
4. Define your data schema using the schema editor
5. Configure your endpoints (GET, POST, PUT, DELETE)
6. Start using your API with the generated URL

Check out our Quick Start Guide for detailed step-by-step instructions.

Yes! Mock API Builder supports importing OpenAPI (Swagger) specifications in JSON or YAML format. You can:

• Upload an OpenAPI 3.0+ specification file
• Paste the specification content directly
• Import from a URL pointing to your spec

The system will automatically parse your spec and create corresponding endpoints and schemas. Learn more in our OpenAPI Import Guide.

Mock API Builder uses Faker.js to generate realistic mock data based on your schema. When you define a field type, the system automatically generates appropriate data:

See our Mock Data Generation guide for all available data types and options.

Yes! You have several options for data:

• Static Values: Use literal values in your schema (e.g., "status": "active")
• Enum Values: Define a list of possible values with helpers.arrayElement
• Seeded Data: Use a seed value to generate consistent data across requests
• Custom JSON: Upload your own JSON data file for complete control

Learn more about data customization in our Schema Design Guide.

By default, list endpoints generate and return 10 records. You can control this with query parameters:

No, data is generated on-the-fly for each request. This means:

• Data will be different each time you make a request
• POST requests don't actually store data
• DELETE requests don't remove data
• The API always returns successful responses with generated data

Mock API Builder supports all standard RESTful HTTP methods:

Each endpoint can be configured to support one or more of these methods.

CORS is automatically enabled for all Mock API Builder endpoints. The API includes:

• Access-Control-Allow-Origin: *
• Access-Control-Allow-Methods: GET, POST, PUT, PATCH, DELETE, OPTIONS
• Access-Control-Allow-Headers: Content-Type, Authorization

This means you can call your mock API from any frontend application without CORS issues. For production APIs, you should configure CORS more restrictively.

Yes! You can configure different status codes for various scenarios:

• Default Behavior: Returns appropriate codes (200 OK, 201 Created, 204 No Content, 404 Not Found)
• Custom Errors: Configure endpoints to return specific error codes (400, 401, 403, 500, etc.)
• Query Parameter: Use ?status=500 to test error handling
• Delays: Add ?delay=2000 to simulate slow responses (milliseconds)

Yes! Use query parameters to filter and sort results:

The filtering behavior depends on your schema configuration. Check our Query Parameters Guide for more advanced filtering options.

To add authentication to your mock API:

1. Go to your project settings
2. Enable "Require Authentication"
3. Generate an API token in your profile
4. Include the token in request headers

Learn more in our Authentication Guide.

Rate limits vary by plan:

When you exceed the rate limit, you'll receive a 429 Too Many Requests response with a Retry-After header.

Here's why you shouldn't use it in production:

• Data is not persistent (generated on-the-fly)
• No real database or data integrity
• Limited by rate limits and quotas
• No uptime SLA or guaranteed availability
• Mock responses may not match real business logic

Best Practice: Use Mock API Builder during development and testing, then switch to a real backend API for production. You can export your schema and use it as a foundation for building your actual API.

Follow these security best practices:

• Never commit tokens to version control - Use environment variables instead
• Rotate tokens regularly - Generate new tokens every few months
• Use different tokens - Separate tokens for dev/staging/production
• Revoke unused tokens - Delete old or compromised tokens immediately
• Store securely - Keep tokens in .env files, never in code