API Endpoint Designer

Design a RESTful API for [DESCRIPTION OF FEATURE/ENTITY]. Consider the following:

**Requirements:**
- Entity: [ENTITY NAME]
- Operations needed: [CREATE, READ, UPDATE, DELETE, SEARCH, etc.]
- Authentication: [AUTH METHOD]
- Rate limiting: [RATE LIMIT POLICY]
- Data volume estimate: [EXPECTED SCALE]

**Deliverables:**

1. **Endpoint Design**: List all endpoints with HTTP methods, paths, request/response formats
2. **Request/Response Schemas**: Define JSON schemas for each endpoint
3. **Error Handling**: Standard error response format with common error codes
4. **Pagination**: Strategy for list endpoints (cursor-based or offset)
5. **Filtering & Sorting**: Query parameter conventions
6. **Security Considerations**: Authentication, authorization, input validation
7. **Versioning Strategy**: How to handle API changes
8. **Example Requests/Responses**: Real JSON examples for 3 key endpoints
9. **Database Schema Suggestion**: Tables/collections and relationships
10. **Performance Tips**: Indexes, caching strategies, N+1 prevention

Make it production-ready with proper status codes (200, 201, 400, 401, 403, 404, 429, 500).

How to Customize It

Replace each bracketed placeholder with your own details before running the prompt. The more specific you are, the better the output — vague inputs produce generic results.

• [DESCRIPTION OF FEATURE/ENTITY]Swap in your description of feature or entity.
• [ENTITY NAME]Swap in your entity name.
• [CREATE, READ, UPDATE, DELETE, SEARCH, etc.]Swap in your create, read, update, delete, search, etc..
• [AUTH METHOD]Swap in your auth method.
• [RATE LIMIT POLICY]Swap in your rate limit policy.
• [EXPECTED SCALE]Swap in your expected scale.

When to Use It

• Speccing a new service's API before writing code, so frontend and backend teams can work against an agreed contract.
• Sanity-checking an existing API against REST conventions before opening it to external consumers.
• Generating the starting point for an OpenAPI spec — ask for the design as an OpenAPI 3.1 YAML document.

Tips for Better Results

• 1Be honest in [EXPECTED SCALE]; the right design for 100 requests/day and 1,000/second differ in pagination, caching, and idempotency choices.
• 2List your ugly edge cases in the description (partial updates, bulk operations, soft deletes) — these are where generic REST advice breaks down.
• 3Ask "what will hurt when this API changes?" as a follow-up; versioning strategy is the section most designs skip.