Home / How to name your API

How to name your API

Naming an API feels trivial until the name has to survive a launch, a docs site and five years of maintenance. This guide walks through a process that works: generate broadly, filter ruthlessly, check legally, then commit.

Step 1 — Brainstorm broadly

Start with quantity, not quality. The goal of a first session is fifty candidates, not five perfect ones. Three techniques get you there fast:

• Seed-word expansion. Write the core domain word (payments, search, auth) and list every synonym, related verb and metaphor you can think of. Then combine them with tech-flavored words: Ledger + Flow = LedgerFlow.
• Pattern forcing. Pick one pattern — compound blends, two-word clarity, or descriptive titles — and generate ten names in that pattern only. Constraints produce more ideas than open brainstorming.
• Constraint flips. After a round, ban your favorite pattern and do another round. The second round usually produces the more original candidates.

A tool like the ApiAlias generator is useful here: feed it a seed word, try each style, and download the shortlist instead of typing names by hand.

Step 2 — Filter ruthlessly

Run every candidate through the same five tests:

1. The hallway test. Say it out loud to a colleague once. If they ask you to spell it, it fails.
2. The search test. Search the exact name in quotes. A collision with an existing product, library or trademark filing is a disqualifier, not a warning.
3. The scope test. Does the name survive your roadmap? "PaymentsAPI" is fine until you add identity verification. Prefer names that hint at the domain without boxing you in.
4. The typing test. Type it ten times. Hyphens, unusual capitalizations and silent letters cost your users every day.
5. The five-year test. Will this name embarrass you at a conference in five years? Trendy suffixes age fastest.

Aim to cut fifty candidates to five. If more than five survive, your filters are too kind.

Step 3 — Check availability

For each surviving finalist, check three things before you fall in love with it:

• Trademark databases. Search your country's trademark office database for identical and confusingly similar marks in relevant classes. This is the check most teams skip and most regret skipping.
• Domains. The exact .com is ideal but not mandatory; a clean .io, .dev or .api-style domain works for developer tools. Check common variants so a squatter cannot impersonate you later.
• Package and handle availability. Search npm, PyPI and GitHub for the name, plus social handles. A name you cannot own consistently across ecosystems will confuse users.

Step 4 — Commit and document

Once a name clears every check, write a one-paragraph naming rationale in your project docs: what it means, what it deliberately does not mean, and the patterns it follows. Future teammates naming endpoints, SDKs and sub-products will thank you — and your naming stays consistent because the reasoning is written down, not remembered.

Then lock the basics: register the domain, claim the handles, and add the name to your naming conventions document so every related name (endpoints, webhooks, SDK packages) follows the same rules.

Key takeaways

• Generate broadly first — fifty candidates before any judging.
• Filter with the hallway, search, scope, typing and five-year tests.
• Trademark search gates the decision; domains are logistics.
• Document the rationale so every future name follows the same logic.