What an extension coverage check can tell you
The extension coverage request checks the same exact registry-level name against published extension datasets. For a domain such as example.com, the checked label is example. It is not a search for spelling variants, trademarks or similar brands.
A broad presence can be useful context when researching a name. It does not establish who owns those registrations, whether they serve active websites, what they are worth or whether your use of the name would be appropriate.
Brand teams can use this first pass to identify extensions needing further inspection. Domain researchers can compare names over a fixed selection of extensions. Both should confirm the live registration and ownership facts before acting.
Read taken, not_found and unknown correctly
- taken: the name appeared in the checked registry snapshot.
- not_found: the name was absent from a dataset that was checked.
- unknown: an explicitly requested extension lacked usable published data and was not checked.
Not found does not mean available to register. Registered domains can be absent from zone files, and registrations change after a download. Use a registrar for current availability and verify the result before attempting a purchase.
Read warnings too. An optional stale_data warning counts extensions using older data while an update is pending. Keep that qualification in your notes; the result is a snapshot observation.
Compare percentage taken with checked coverage
percentage_taken = taken / checked × 100, rounded to two decimal places. Unknown extensions are excluded from the denominator.
Illustrative example: you request 20 extensions. The name is found in 12, absent in 3 and unknown in 5. Fifteen were checked, so percentage taken is 80%, not 60%. Keep both 80% and the 15 checked extensions in your report.
Use the same extension selection and similar snapshot dates for comparisons. A result of 100% across two checked extensions does not describe the same breadth as 100% across 200. A percentage alone conceals that difference.
Choose broad discovery or a fixed comparison
Omit suffixes to check all published datasets. New datasets join after their first publication; an approval awaiting import is not yet coverage.
Pass a fixed comma-separated suffixes selection when comparing several names on the same basis. Request include_taken=1 or include_not_found=1 when you need the individual extension lists; both are omitted by default while summary counts remain.
The extension coverage API reference and examples show authentication, compound suffixes, response fields and errors. A successful check costs one credit total, including partial coverage. If none of the requested datasets can be checked, the endpoint returns an unavailable error without charging.
Add the evidence your decision requires
Use live registration checks and appropriate name-rights research for a purchasing or brand decision. Visit found domains if you need to understand how the name is being used; presence in a snapshot does not mean an active business or website.
If the decision also depends on existing links, check domain metrics and backlink evidence separately. Extension presence and link authority answer different questions and have separate credit costs.
Retain your selected extensions, checked count and warnings with the result. Use data within the service terms; API access does not grant redistribution rights.
Questions
Does not_found mean that I can register the domain?
No. It means the name was absent from the snapshot checked. Confirm current availability with a registrar before purchasing.
Does extension coverage include every registered domain?
No. It uses published registry datasets. Registered names can be absent from zone files, and an explicitly requested extension without a dataset is unknown.
Do optional extension lists cost extra?
No. A successful extension coverage request costs one credit total whether you request summary counts only or the optional lists, including partial coverage.