Endpoints that don't suck
Generate clean, convention-following REST API endpoint names instantly. Type a resource, pick your actions, and get a full CRUD set — plural nouns, kebab-case, no verbs, versioned — ready to paste into docs, mocks and prototypes. 100% in your browser. No signup. No server.
Singular or plural — the machine pluralizes and kebab-cases it for you. Try "order item", "blogPost", "user".
Adds a nested collection: /users/{userId}/orders. Keep nesting to one level.
Most APIs namespace everything under /api.
Version in the URL is the most common approach for public APIs.
Uncheck what you don't need. The machine rebuilds instantly.
Your endpoints will appear here. Click any row to copy it.
Honest limits — read before you ship
- These are naming examples for docs, mocks and prototypes — not a finished API design. Real APIs need auth, error formats, pagination contracts and rate limits that no name generator provides.
- The pluralizer is deliberately naive. It handles common English patterns (order → orders, category → categories) but will mangle irregular words — always eyeball the output.
- Conventions are applied automatically, but your team's style guide wins. If your API uses a different versioning scheme or naming style, follow it consistently instead.
- Best used for: API documentation drafts, frontend mocks, teaching REST conventions, prototyping, and design reviews.
How the machine works
No accounts, no network calls. A small JavaScript file builds every endpoint on your device.
Normalize your words
Type "blogPost", "order item" or "Category" — the machine lowercases, kebab-cases and pluralizes every resource name automatically, so the output always looks like a real API.
Assemble the CRUD set
List, get-one, create, replace, update and delete — each mapped to the right HTTP method, with {id} placeholders, optional nesting and a filter/sort/page query example.
Copy it anywhere
Click any endpoint to copy it, copy the whole set, or download a .txt file for your docs, mock server or API design review. Everything stays in your tab.
Quick answers
Should endpoints use singular or plural nouns? +
Plural for collections — /users, not /user. The same path with an ID addresses one item: /users/123. Plural-only is the dominant convention in modern APIs. Full conventions guide.
Can I put verbs in endpoint paths? +
Avoid it. The HTTP method is the verb: POST /orders, not /createOrder; GET /users/123, not /getUserById. Nouns name the resource; methods name the action.
How deep should I nest resources? +
One level is normal; two is a smell; three is almost always wrong. Deep paths like /a/1/b/2/c/3 couple your URLs to your data model. Prefer top-level resources with filtering. Nesting guide.
Where does the version go? +
The most common approach is in the URL: /v1/users or /api/v1/users. Alternatives include headers or content negotiation, but URL versioning is the most visible and the easiest for clients to use.
How do I name filter, sort and pagination? +
Use query parameters, not path segments: /users?status=active&sort=created&page=2&pageSize=20. The path identifies the resource; the query selects the view.
Is the generator really private? +
Yes. EndpointEcho is plain JavaScript in your browser. Nothing is sent over the network, no cookies are set, nothing is stored. See the privacy page.
API naming guides
Short, opinionated guides on REST endpoint naming: the conventions, the examples, and the traps.
REST API naming conventions
The eight rules behind every well-named API: nouns, plurals, kebab-case, hierarchy, versioning and more.
Read guide → ExamplesEndpoint examples
Full CRUD matrices for users, orders and products — plus sub-resources and query patterns.
See examples → GuideNesting & versioning
When to nest, when to flatten, and where the version number actually belongs.
Read guide →