Webmaster.ninja was a suite of tools developed by using WhoAPI APIs.
Which APIs were used, and how they worked
So many APIs were used while we were building webmaster.ninja. It’s hard to start with one. Perhaps we can start with the one most visual of all the APIs.
Screenshot API
Screenshot API was used to fetch the thumbnail of all the websites in a client’s portfolio. During the beta stages of webmaster.ninja development on the tools helped us improve the Screenshot API as well. As you can see from the images below, at first, we also had errors and partial screenshots.
But after several updates, we managed to get a satisfying result. Not just for our suite of tools (website monitoring) but for all our WhoAPI clients who were using Screenshot API.
The end result was that Screenshot API was working much better. And webmaster.ninja tools and monitoring were also better. What you see above is the beta of webmaster.ninja dashboard. We ended up building a much better UX/UI. You can see it below.
One of the sections closest to the beta examples above is the portfolio overview.
Whois API
Suppose you were looking closely at the screenshots above. Surely you’ve seen domain registrar info, registration dates, domain expiration dates, and so on. For that information, we’ve used our Whois lookup API.
It worked extremely well, and we used it in two situations.
- Whois API displayed critical domain name information to the client’s portfolio. In a single screen, the client could see where the domain name (website) was hosted (nameserver). Where the domain name was registered (domain registrar) And other critical data.
- We also built a DomainWatch service that checked the domain name expiration dates. As the expiration date was approaching, we would notify the client.
SSL API
Another critical component of any website is the SSL certificate. When SSL certificates expire, website visitors are left with a warning and they leave the website scared. With our SSL API we were able to get the SSL expiration date and warn the website owner. Since we already had a website screenshot from our other API, we can show the website owner what the website looks like.
All this was done in a very cost-effective way, and we tried different price points.
Our main priority remained and stayed. Test our APIs, improve them during this process, and “eat our own dog food” as they say in the startup world.
Blacklist API
As you know, we also have a blacklist API. In webmaster.ninja we essentially created an email blacklist monitoring service. All the user had to do was type the domain name once, and the system would do the rest. We would periodically check the popular email blacklists, and if we found the said domain name / IP Address, we would notify the user.
Notification was done in two ways. We would email the user, and display the warning inside a notifications center. Notifications center served for all the messages (domain expiration, SSL expiration, blacklist notification, etc.)
This is what it looked like.
Email Score API
Email Score API was used on the backend. The user didn’t know this, but each time someone would sign up, we would rate their email address.
This was important to us because we also had a free plan. As I mentioned in the beginning of this article, we had thousands of free users. We needed an automatic way to give more attention to high-value email addresses.
Domain Availability API
Lastly, we used our Domain Availability API to build an bulk domain checker, that actually worked.
Naturally, with it you could just check if a single domain name is available for registration. But, as we know that finding a good domain name is sometimes like finding a needle in a haystack… Our bulk domain checker allowed you to combine two or three sets of keywords.
I already wrote in depth how it worked in an article “How to find incredible .com domains”. This bulk domain checker made it easy to find geo-domains, EMDs (exact-match domains), short brandable domains and just fun domains.
Build it, and they will come, doesn’t work
The service had other bells and whistles, making it hard an expensive to manage as a hobby project. As I mentioned, at first, I started this project as a way to test and use our APIs. We ended up getting some traction with thousands of free users, and a few dozen paying clients. The clients started upgrading once I lower the prices to $5.
However, at that price point, you need to have 1000 paying clients in order to get a minimum of some sort of meaningful amount. We just didn’t get there.
