Back to All Discussions
When will the Whois 2.0 API level up from beta?
mariusbutuc
9 years ago
Hi there,
First of all, thanks for exposing the NameToolkit API; I find it very useful.
I also find the
{ "available": false, "status": "registered", [...] }- versus
{ "available": true, "status": null, [...] }
details in the Whois 2.0 API very convenient and useful.
When would you expect the Whois 2.0 API to mature and get out of beta?
Thanks,
Marius
Join in the discussion - add comment below:
Login / Signup to post new comments
Awesome, thanks for the details.
Making 5000 GETs (as long as they’re all .com or .net domains) should be fine even on the 2.0 API. It’s exactly what we’d be doing if we had a bulk call, and other API users make this amount of requests in one go.
As regards Thin/Think whois lookups, a decent explanation I found:
"Thick and Thin Registries
The .com and .net are called “Thin” registries. This is because the registry does not keep the entire whois record. They just keep the registrar and the name servers. The registrars are responsible for keeping the entire whois record. This was done in the late 1990’s because Network Solutions had a monopoly and when competition was introduced the concern was that they would use their market position to take business from the new registrars. Even though this is not relevant anymore the system has never been changed.
Other registries are “Thick” registries and they maintain the entire whois record."
What do you mean by thin lookups? Is a GET to
https://nametoolkit-name-toolkit.p.mashape.com/beta/whois/example.comconsidered a thin lookup?I’m interested in deciding which out of 5,000 .com domains are available and which ones are registered, ideally in one go.
If there isn’t a bulk option that does this in (close to) real-time, would 5,000 GETs to
https://nametoolkit-name-toolkit.p.mashape.com/beta/whois/{domain}be even something to consider?Hi Marius,
You should be ok there; .com lookups, thin ones at least (which means relating to availability rather than returning full address details) are pretty plentiful per IP so you should be ok there. We used to run our website from one IP for years without blocks on .coms.
Actually, maybe a quick win in the meantime.
You’re saying that API v2.0—not running on your distributed lookup infrastructure yet—is more prone to getting throttled by TLD registries like
.edu.If the scope would be narrowed down to
.com-only, is this still an issue?Thanks and looking forward. That would be great news indeed!
Hi Marius,
Support is split between our 2 API versions atm, and 2.0 hasn’t had enough love, even though it’s better structured. It needs to run on our distributed lookup infrastructure whereas the 1.0 API already uses it. This means it gets throttled too easily by certain TLD registries e.g. .edu. I’ll get back to you in a few days on this, shouldn’t be hard to improve these details.