DEV Community: Furqan Ashraf

Detect Account Takeover in Node.js: A Free Login Location Check

Furqan Ashraf — Wed, 19 Aug 2026 22:20:33 +0000

Someone logs into an account from New York. Forty minutes later, someone logs into the same account from Lagos, roughly 8,400 km away. Nobody makes that trip in forty minutes. Whoever just logged in from Lagos almost certainly isn't the same person who logged in from New York, and there's a decent chance the app in question has no idea that just happened.

That's the whole pitch for impossible travel detection, and if you spend any time on dev.to's security tag, you've probably already read an explanation of it. The concept isn't new and it isn't complicated: geolocate the login, measure the distance from the last one, divide by the time between them, check if the result is physically possible. What's rarer is finding the tested, installable version of that logic instead of a snippet you're expected to adapt yourself. So I built one.

impossible-travel-guard is free, open source, and has zero runtime dependencies. Install it, call one function after your login check passes, done. This post covers what it actually catches, where it falls apart, and how to feed it real coordinates without writing your own geolocation client.

Why this is worth shipping, not just explaining

Account takeover isn't a fringe problem. The FBI's IC3 unit logged close to 4,700 ATO complaints in 2025 with $359.7 million in reported losses, and their own numbers show that once an attacker actually gets into an account, fifty or more transactions across different banks can fire off within minutes (source). That's not someone clicking around by hand, that's a script doing damage fast once it's past your login screen. Anything that slows down the "getting in" part earns its keep.

What makes this particular signal useful is that it doesn't need either IP address to look suspicious on its own. No VPN flag, no bad reputation score, nothing wrong with either login individually. The only thing wrong is the relationship between them. Most account security tooling checks a login against a blacklist or a reputation score. This checks a login against the user's own history, so it still catches an attacker coming from a completely clean IP, because they didn't think they needed to hide it.

That also means it will occasionally flag things that are completely fine. More on that below, because it's the part that decides whether this is actually useful in production or just a fun demo.

Installing it

npm install impossible-travel-guard

Five lines gets you a working check:

import { TravelGuard } from "impossible-travel-guard";

const guard = new TravelGuard(); // in-memory store, fine for local dev

const result = await guard.check({
  userId: "user_123",
  latitude: 6.5244,
  longitude: 3.3792,
  timestamp: Date.now(),
});

if (result.flagged) {
  // require MFA, alert the user, or hold the session for manual review
  // do not hard-block on this signal alone, more on that below
}

The first login for any user is never flagged. There's nothing to compare it to yet, so it just becomes the baseline everything else gets measured against.

That in-memory store is fine for poking at this locally, and it forgets everything on restart. For anything real, implement the two-method LoginStore interface against whatever you already run. Redis is a natural fit since this is one small read and one small write per login:

import { LoginStore, LoginEvent } from "impossible-travel-guard";

class RedisStore implements LoginStore {
  async getLastLogin(userId: string): Promise<LoginEvent | null> {
    const raw = await redis.get(`last_login:${userId}`);
    return raw ? JSON.parse(raw) : null;
  }
  async saveLogin(event: LoginEvent): Promise<void> {
    await redis.set(`last_login:${event.userId}`, JSON.stringify(event));
  }
}

const guard = new TravelGuard({ store: new RedisStore() });

Picking the threshold

Two numbers control how sensitive this is:

new TravelGuard({
  maxPlausibleSpeedKmh: 1000, // default
  minDistanceKm: 50,          // default
});

1000 km/h isn't a number I picked out of the air. Commercial jets cruise between roughly 830 and 1,050 km/h, and the fastest passenger aircraft flying today tops out around 1,136 km/h. 1000 sits above normal cruise speed with margin for geolocation being a little imprecise, without being loose enough to let a real cross-continent jump slide under it. minDistanceKm exists for a dumber reason: IP geolocation jitters within the same city all the time, and without a floor you'd flag someone whose ISP handed them a slightly different IP on the same Wi-Fi network.

Turn the speed threshold down if your users rarely fly internationally. Turn it up if you'd rather only catch the most extreme jumps and tolerate more noise.

The false positives you'll actually hit

I ran this against enough test scenarios before publishing to know where the flags actually come from in practice, and it's rarely the interesting case:

Cause	Why it trips the check	What to do about it
Corporate VPN or privacy relay	Traffic exits through a server nowhere near the user	If the device is recognized, log it and move on. If not, step up
Mobile carrier CGNAT	The carrier's gateway can sit hundreds of km from the actual phone	Keep `minDistanceKm` above typical carrier drift
Same-city IP reissue	A new DHCP lease or repeat lookup lands a few km away	This is what `minDistanceKm` is for, it shouldn't reach you at all
An actual compromised login	Attacker logging in from their own, unmasked location	The reason this library exists. Step up first, block if it stacks with other signals

That last row is the reason to build this at all. VPN and IP-reputation checks catch the attackers sloppy enough to route through something flagged. This catches the ones who don't bother hiding, because a stolen password from a data breach doesn't come with instructions to use a VPN.

The practical takeaway from that table: never wire a flag straight to a hard block. Log it first, watch what comes through for a week, and only start requiring MFA on a flag once you've seen your own users' actual travel patterns. Reserve an outright block for when a flag stacks with something else, a new device, a new browser, a password reset requested minutes earlier.

What this won't catch

This is one signal, not a fraud engine. It has no opinion on VPNs, proxies, device fingerprints, or IP reputation, pair it with those if you want that coverage, I didn't try to make this library do five jobs at once.

It also can't tell you why a trip is impossible, only that it is. A shared corporate VPN egress bouncing between two data centers looks exactly the same to this library as a real account takeover does. iPhones behind Apple's Private Relay cause the same kind of noise. None of that is specific to this package, it's true of any impossible-travel check anyone builds, and the honest fix is the boring one: log enough context on every flag that you can review a handful by hand until you trust the threshold you've picked.

Getting coordinates without building your own geolocation client

This library never calls a geolocation API itself. That's deliberate, so it works with whatever provider you already have. If you don't have one, IPGeolocation.io's IP Location API covers exactly what this needs on its free tier, latitude, longitude, city, and country for an IP, no card required for a key. The repo's examples/ipgeolocation-adapter.ts has a working version of that wiring, and examples/live-test.ts runs the whole flow against two real IP addresses so you're looking at actual coordinates instead of the hardcoded ones in the quick-start snippet above:

export IPGEO_API_KEY="your-key-here"
npx tsx examples/live-test.ts 8.8.8.8 197.210.28.1 40

That resolves both IPs, runs the exact check guard.check() runs, and prints the distance, elapsed time, and implied speed. One thing worth saying plainly: never call a geolocation API directly from a browser with your key in the request. That belongs on your backend, full stop.

A few things people ask

Does this replace VPN or IP reputation checks? No, and I'd be skeptical of anything that claims one signal does. It catches a different kind of attacker, one whose IP has no reputation problem at all. Run it alongside VPN and proxy detection if you want broader coverage, not instead of it.

What data does this actually need? Latitude, longitude, and a timestamp per login. That's it. Nothing paid, nothing beyond what any geolocation provider's free tier already returns.

Is the library itself free? Yes, MIT licensed, no paid tier of its own. The only cost that could show up is whichever geolocation provider you pick, and a free tier is enough for what this needs.

Will this lock out real users? Not if you respond to a flag with step-up verification instead of a hard block, which is what the rest of this post has been arguing for. Treat a flag as "ask one more question," not "deny access."

Try it before you install it

There's a live demo that runs this exact logic in your browser. Pick two cities, set a time gap, watch it flag or clear. I built that after realizing a passing test suite that only I'd seen wasn't proof of anything to anyone else, and it's a faster way to get a feel for the threshold than reading about it.

The GitHub repo has the full source, the test suite, and both example scripts above. Issues and pull requests are genuinely welcome, if you hit a false positive or false negative worth handling differently, open one with the two real login events involved. Real numbers make it easy to reason about.

Building a Typosquat Detector with Python and a WHOIS API: A Technical Walkthrough

Furqan Ashraf — Tue, 18 Aug 2026 14:37:49 +0000

I open sourced a small tool recently for flagging suspicious domains, and a few people asked how it actually works under the hood rather than just what it does. So here's the technical side: the design decisions, the tradeoffs, and why I built it this way instead of a few obvious alternatives.

Repo is here if you want to skip ahead: https://github.com/Furqan-Ashraf/Typosquat-detector

The problem with checking domains one at a time

If you've ever tried to script anything around WHOIS data, you've probably hit the same wall I did. Raw WHOIS responses aren't structured. They're plain text, and the format changes depending on the registrar and the TLD. Some responses have a Creation Date field. Others have created. Others bury it three lines deep in a block of legal text you have to skip past first.

Writing a parser that handles even a handful of TLDs reliably takes real effort, and it breaks the moment you hit a registry you didn't test against. This is the main reason I used a WHOIS API (WhoisFreaks, specifically) instead of building a raw WHOIS parser from scratch. It returns normalized JSON, so the code doesn't care whether it's looking at a .com, a .io, or a .dev domain. Same fields, same structure, every time.

Two independent checks, combined

The core logic is intentionally simple: two checks, each cheap to compute, combined into one risk flag.

Check one: registration age. This one's a straightforward date diff once you have the creation date:

def parse_age_days(create_date_str):
    for fmt in ("%Y-%m-%d", "%Y-%m-%dT%H:%M:%SZ", "%Y-%m-%d %H:%M:%S"):
        try:
            created = datetime.strptime(create_date_str, fmt).replace(tzinfo=timezone.utc)
            return (datetime.now(timezone.utc) - created).days
        except ValueError:
            continue
    return None

Multiple date formats are handled because different registries return dates differently even through a normalized API. Better to try a few formats than crash on the one registry that's slightly different.

Check two: string similarity against a watchlist. This is Levenshtein distance, implemented without any external dependency since it's a small enough algorithm not to warrant pulling in a library:

def levenshtein(a, b):
    if a == b: return 0
    if not a: return len(b)
    if not b: return len(a)
    prev = list(range(len(b) + 1))
    for i, ca in enumerate(a):
        cur = [i + 1]
        for j, cb in enumerate(b):
            cur.append(min(prev[j+1]+1, cur[j]+1, prev[j]+(ca != cb)))
        prev = cur
    return prev[-1]

This is the classic dynamic programming approach, O(n*m) where n and m are the string lengths. For domain names, which are short strings, this runs instantly even across a large watchlist.

One bug worth mentioning, since it's the kind of thing that only shows up once you test against real-world typosquat patterns: comparing the full base string against the watch domain misses cases where the attacker adds extra text, like paypa1-secure.com against paypal.com. The full-string edit distance there is large enough to fall outside any sane threshold, even though it's an obvious typosquat to a human. Fixed it by also sliding a same-length window across the candidate string and taking whichever comparison, full string or windowed, gives the smaller distance:

def closest_watch_match(domain, watch_domains):
    base = strip_tld(domain)
    best_domain, best_distance = None, None
    for watch in watch_domains:
        watch_base = strip_tld(watch)
        full_dist = levenshtein(base, watch_base)

        window_dist = full_dist
        w = len(watch_base)
        if len(base) > w:
            window_dist = min(
                levenshtein(base[i:i + w], watch_base)
                for i in range(len(base) - w + 1)
            )

        dist = min(full_dist, window_dist)
        if best_distance is None or dist < best_distance:
            best_domain, best_distance = watch, dist
    return best_domain, best_distance

Small fix, but it's the difference between catching paypa1-secure.com and missing it entirely, which matters a lot more than the character-swap case since real phishing domains almost always pad the name with something like -secure, -support, or -login.

Why combine them instead of scoring separately

An earlier version of this scored age and similarity separately and ranked domains by a weighted total. I dropped that pretty quickly. Weighted scoring sounds more sophisticated, but in practice it just makes the threshold harder to reason about, and harder to explain to anyone else looking at the flagged list. A boolean AND, new domain and close lookalike, both true, is easy to tune (two thresholds, both adjustable as plain variables at the top of the script) and easy to explain to someone reviewing the output.

result.risk_flag = result.is_new and result.is_lookalike

That's the entire decision. Everything before it in the script is just gathering the two inputs.

Handling the API layer

A few things mattered here beyond just making the request:

Rate limiting courtesy. There's a small sleep between requests (REQUEST_DELAY_SECONDS = 0.3). Nothing fancy, just enough to avoid hammering the API on a large batch.

Graceful degradation. If a lookup fails for one domain (timeout, malformed response, whatever), that shouldn't kill the whole batch. Errors get caught, logged into the result object, and the script moves on to the next domain:

try:
    data = query_whoisfreaks(domain, api_key)
    # ...
except requests.exceptions.RequestException as e:
    result.error = f"Request failed: {e}"

Dataclasses for structured results. Each domain check produces a DomainResult dataclass rather than a loose dictionary. Makes the CSV export trivial (asdict() handles the conversion) and keeps the fields self-documenting.

What I'd add next

The repo's open for contributions, and a few extensions are on my list:

DNS and nameserver cross-referencing would add a third signal, since a lot of phishing infrastructure reuses the same nameservers across multiple campaigns even when the domain names differ. SSL certificate issuance date is another one worth adding, mainly because a domain with no cert, or one issued the same day as registration, tends to correlate with the same short-lived infrastructure pattern.

Async requests would help too. Right now it's sequential with a delay, which is fine for a few hundred domains but slow if you're trying to batch-check thousands.

Where to get it

The full script, README, and usage instructions are on GitHub: https://github.com/Furqan-Ashraf/Typosquat-detector. If you're running something similar, or you've layered in other signals (SSL, DNS, ASN data) that work well for this kind of detection, I'd be curious to hear about it.

If you want the fuller story behind why I built this in the first place, I wrote that up separately here: I Built a Script to Catch Phishing Domains Before They Hit My Inbox

Someone Registered a Fake Version of Your Domain. Here's How to Detect It Before Your Customers Get Scammed

Furqan Ashraf — Thu, 06 Aug 2026 13:44:40 +0000

Picture this. Your company owns paypal.com. Somewhere, someone just registered paypa1.com, swapping the letter L for the number 1. At a glance, in most fonts, nobody can tell the difference. That new domain isn't live yet. Maybe it never will be. Or maybe in three weeks it's hosting a fake login page, harvesting your customers' passwords, and quietly ruining your brand's reputation.

This happens constantly, and most companies never know it's happening until a customer complains, or worse, until it shows up in the news.

Why this keeps happening

Registering a lookalike domain costs almost nothing, often less than the price of a coffee. Attackers use a few common tricks:

Character typos: swapping, dropping, or duplicating a letter (gooogle.com, googel.com)
Keyboard slips: substituting a letter with the one next to it on a QWERTY layout
Homoglyphs: using characters that look nearly identical, like a capital "I" instead of a lowercase "l"
Compound squats: adding a word to the brand name, like yourbrand-login.com or yourbrand-support.net

Any one of these can be used for phishing, credential theft, fake customer support pages, or straight-up brand impersonation. And here's the part most teams miss: even if you know typosquatting exists, actually finding which lookalike domains are currently registered against your brand is a different problem entirely, and knowing whether a domain you found is actually dangerous is a third problem on top of that.

Problem 1: Finding the fake domains in the first place

You can't manually guess every possible misspelling of your brand across 1,500+ domain extensions. Free permutation tools exist, but most of them work by generating typo candidates locally and then resolving each one with a DNS lookup from your own machine. That misses compound squats, wildcard patterns, and anything the generator didn't think to produce. It also means you're the one running potentially thousands of DNS queries just to check.

A more direct approach is to search the domains that are actually registered, instead of generating guesses and hoping one resolves. WhoisFreaks' Domain Typosquats API works this way. You send it a brand keyword, and it searches across 931 million plus registered domains and 1,529+ TLDs for fuzzy matches.

curl --location 'https://api.whoisfreaks.com/v3.0/domain/typos?keyword=yourbrand&apiKey=YOUR_API_KEY'

The response comes back with every matching registered domain, along with its creation date, expiry date, and when it was last seen active. Here's a trimmed version, the real response also includes pagination fields for stepping through large result sets:

{
  "status": true,
  "totalRecords": 42,
  "domains": [
    {
      "domainName": "y0urbrand.com",
      "createDate": "2026-06-02",
      "expiryDate": "2027-06-02",
      "lastSeen": "2026-08-01",
      "isDropped": false
    }
  ]
}

You can also search with a wildcard pattern instead of a plain keyword, which catches prefix, suffix, and hyphenated variants that a simple typo match would miss, things like yourbrand-support.com or login-yourbrand.net.

Problem 2: Not every lookalike domain is actually dangerous

Here's the catch. Once you run a scan, you'll likely get back a list of dozens, sometimes hundreds, of matching domains. Most of them are harmless. Some are parked and doing nothing. Some belong to unrelated small businesses that happen to share a similar name. A handful might be actively serving a phishing page right now.

Treating every result the same way, either ignoring all of them or trying to escalate all of them, isn't practical. What you actually need is a way to separate "genuinely dangerous" from "just similar looking."

This is where a second check comes in. WhoisFreaks' Domain Reputation API takes a single domain and returns a risk verdict, a trust score from 0 to 100, and the evidence behind it. Under the hood, it runs live WHOIS, DNS, SSL, and page content checks, plus a match against WhoisFreaks' own threat intelligence feeds, all in one request.

curl --location 'https://api.whoisfreaks.com/v1/domain/security?domainName=y0urbrand.com&apiKey=YOUR_API_KEY'

A simplified version of what comes back:

{
  "risk_category": {
    "verdict": "suspicious",
    "severity": "high",
    "primary_threat": "phishing"
  },
  "trust_signals": {
    "trust_score": 12,
    "trust_band": "low",
    "indicators": {
      "is_newly_registered": true,
      "has_dmarc": false,
      "uses_free_ssl": true,
      "domain_age_days": 24
    }
  },
  "intelligence": {
    "recommended_action": "block"
  }
}

A domain that's a few weeks old, has no email authentication set up, is running on a free SSL certificate, and redirects somewhere unexpected checks almost every box that real phishing infrastructure tends to check. A trust score in the low band plus a "block" recommendation tells you this one deserves immediate attention, unlike a similar-looking domain that's been sitting parked and unused for three years.

Putting both checks together

Used separately, each API answers half a question. Used together, they form a simple, repeatable workflow:

Brand keyword
     ↓
Typosquats API → list of registered lookalike domains
     ↓
Domain Reputation API → trust score + verdict for each one
     ↓
Result: block, monitor, or ignore

In practice, this means running a keyword or pattern scan against your brand on a schedule (daily or weekly works for most teams), then automatically feeding every new result through a reputation check. Anything that comes back with a low trust score or a "malicious" verdict gets flagged for your security team immediately. Everything else can wait for a routine review, or get ignored entirely if it's clearly unrelated or parked.

This is a small amount of glue code, a scheduled job and two API calls, but it replaces what used to require someone manually checking a list of domains one at a time.

Who actually needs this

This workflow is most useful for:

SaaS companies, where a fake login page can lead directly to account takeover
Banks and fintech, where impersonation directly threatens customer trust and money
E-commerce, where fake storefronts scam customers out of payment details
SOC and security teams, who need this fed into existing SIEM or SOAR pipelines rather than checked by hand
MSSPs and anti-phishing vendors, who need to offer this kind of detection as a feature to their own clients

The bigger point

Most companies never check for this until something already went wrong, a customer forwards a suspicious email, or a fake site gets reported after it's already scammed people. Finding lookalike domains early, before they turn into active phishing infrastructure, is the difference between a quiet defensive registration and a real incident response.

The two checks aren't complicated on their own. What makes the difference is running them consistently, and actually acting on what they tell you.

Stop Guessing Why Your SQL Query Is Slow: A Simple Guide to EXPLAIN

Furqan Ashraf — Wed, 05 Aug 2026 09:00:21 +0000

If you are just getting started with SQL, you have probably written a query that worked fine while testing, but felt slow once the table had more data in it. This happens to almost everyone, and it does not mean you did something wrong. It usually just means the database is not being used in the most efficient way yet, and that is a normal part of learning.

This article walks through how to understand why a query might be slow, in simple terms, without needing to be an expert.

First, understand what the database is actually doing

When you write a query, you might imagine the database just "looks through the table" to find the data. In a way, that is true, but there is more to it. Before running your query, the database makes a small decision internally: how should it go through the table to find what you asked for? Should it check every single row, or is there a faster shortcut it can use?

That decision is what really controls how fast or slow your query feels. Two queries that look almost the same can behave very differently depending on this.

The good news is you do not have to guess. Most databases let you ask them directly what they plan to do, before actually running the query. In MySQL and PostgreSQL, you do this by adding the word EXPLAIN in front of your query:

EXPLAIN SELECT customer_id, total_amount
FROM orders
WHERE status = 'pending';

This will not return your actual data. Instead, it shows you the plan, almost like a summary of what the database is about to do. You do not need to understand every detail of this output right away. Just look for one simple thing: is the database checking every row in the table, or is it jumping straight to the rows that match?

If your table only has a few hundred rows, checking every row is usually fine and you will not notice any delay. But once a table grows to thousands or millions of rows, checking every single row becomes slow, and that is usually the real reason behind a slow query.

What an index actually does (in simple terms)

You have probably heard the word "index" mentioned around database performance. An index works a bit like the index page at the back of a textbook. Instead of flipping through every page to find a topic, you check the index page, and it tells you exactly where to look.

A database index works the same way. Instead of scanning the whole table, the database can jump straight to the matching rows if there is an index on the right column.

For example, if you often search orders by their status:

CREATE INDEX idx_status ON orders(status);

This tells the database to keep a quick lookup list for that column, so future searches on status do not need to scan the entire table.

One important tip: an index only helps if your query searches using that exact column in a simple way. If you wrap the column inside a function, like checking only the year from a date column, the database usually cannot use the index anymore, even if one exists. It is better to compare the raw column directly whenever possible.

Also, indexes are not something you should add to every column "just in case." They do help with reading data faster, but they slightly slow down adding or updating data, since the database has to update the index too. For now, it is enough to know this trade-off exists. You will get a feel for when to use indexes as you write more queries.

A few simple habits that make a real difference

You do not need advanced tricks to write faster queries. A few small habits go a long way, especially while you are still learning.

Only ask for the columns you actually need. It is common to write SELECT * out of convenience. This asks the database for every single column, even ones you might not use. Once you know which columns you actually need, it is better to name them directly:

SELECT name, email FROM customers;

This is lighter for the database and easier to read too.

Avoid pulling more rows than you will show. If you are only displaying twenty results on a page, there is no need to ask the database for thousands of rows and filter them later in your code. Use LIMIT to ask the database to only return what you need:

SELECT * FROM articles LIMIT 20;

Be careful with pagination on large tables. A common approach when starting out is something like LIMIT 50000, 20, meaning "skip fifty thousand rows, then give me the next twenty." The problem is the database still has to go through those fifty thousand rows first, even though you do not want them. As your data grows, this gets noticeably slower.

A simpler and faster habit is to filter using the last row you already saw, instead of skipping by a number. For example, instead of:

SELECT * FROM posts
ORDER BY id
LIMIT 50000, 20;

track the last ID you saw on the previous page, then do this:

SELECT * FROM posts
WHERE id > 5000
ORDER BY id
LIMIT 20;

The database can jump straight to id > 5000 using the index, instead of counting through 50,000 rows first just to skip them. The same idea works with a timestamp column too, if you are paginating by date instead of ID.

None of these habits require deep expertise. They are just small choices that matter more as your tables grow bigger.

Query speed is something you check now and then, not just once

When you are still new to this, it is easy to think performance is something you fix one time and forget about. In reality, a query that runs fine today might feel slow months later, simply because the table has grown. This is completely normal, and experienced developers deal with the same thing.

A good habit going forward is this: whenever a query feels slower than expected, run EXPLAIN on it first before changing anything. It takes the guesswork out of the process and shows you exactly where the slowdown is coming from.

If you are still building your SQL foundations and want a simple, step by step place to start, APIFreaks has a free SQL tutorial series that covers the basics in order, from what a table is, all the way through joins, subqueries, and views. It is a good next stop before diving deeper into topics like performance and optimization.

7 APIs Every Developer Should Know About (But Probably Doesn't)

Furqan Ashraf — Tue, 09 Jun 2026 12:14:06 +0000

Most developers know about Stripe, Twilio, and Google Maps.

Those are the popular ones. Everyone uses them. Everyone writes about them.

But there's a whole layer of APIs that quietly power real-world apps, and most developers never hear about them until they need them badly.

This list is for those APIs.

Each one solves a specific, practical problem. Each one has a free tier. And together, they can power a surprisingly large chunk of a real product.

Let's get into it.

1. IP Geolocation API

What it does: Tells you where an IP address is coming from.

Not just the country. Think city, timezone, ISP, currency, language, and even whether the request is coming through a VPN or proxy.

Why developers need it:

Show the right currency based on location
Block traffic from certain regions
Detect suspicious logins from unexpected locations
Redirect users to the right regional version of your app

Real use case:

A SaaS app detects that a user suddenly logged in from a different country than usual. Was it a trip or a compromised account? The IP geolocation API gives you the first clue.

Where to get it: IPGeolocation.io has a generous free tier and solid documentation. One API call returns everything: location, timezone, currency, VPN/proxy status, and more.

{
  "ip": "8.8.8.8",
  "country_name": "United States",
  "city": "Mountain View",
  "time_zone": { "name": "America/Los_Angeles" },
  "currency": { "code": "USD" },
  "security": { "is_vpn": false, "is_proxy": false }
}

2. WHOIS and Domain Intelligence API

What it does: Lets you look up everything about a domain name programmatically.

Registration date, registrar, expiry date, name servers, historical WHOIS records, reverse WHOIS lookups.

Why developers need it:

Fraud prevention: Is this domain newly registered? Big red flag.
Competitor research tools
Security tools that track domain ownership changes
Due diligence before purchasing a domain

Real use case:

A fintech app lets users pay via business email. Before processing, it checks if the domain in the email was registered in the last 7 days. If yes, it flags the transaction. This is a classic fraud signal that WHOIS data can catch instantly.

Where to get it: WhoisFreaks.com covers WHOIS lookup, DNS lookup, reverse WHOIS, and historical records. All accessible via API.

GET https://api.whoisfreaks.com/v1.0/whois?apiKey=YOUR_KEY&whois=live&domainName=example.com

3. Currency Exchange Rate API

What it does: Returns live and historical currency exchange rates for 150+ currencies.

Why developers need it:

E-commerce apps showing prices in local currency
Finance dashboards tracking portfolio value
Invoice tools that bill in multiple currencies
Any app that touches money across borders

Real use case:

A freelancer invoicing tool needs to show EUR, GBP, and PKR rates relative to USD. Instead of scraping random websites or using outdated hardcoded values, you hit one endpoint and get accurate, up-to-date rates.

Where to get it: CurrencyFreaks.com provides live rates, historical rates, and currency conversion in one place. Clean API, free plan available.

{
  "base": "USD",
  "rates": {
    "EUR": 0.92,
    "GBP": 0.79,
    "PKR": 278.50
  }
}

4. Commodity Price API

What it does: Returns live and historical prices for commodities like gold, silver, oil, wheat, natural gas, and more.

Why developers need it:

Fintech and investment tracking apps
Agricultural platforms
Economic data dashboards
Any app that needs real-world asset pricing

Real use case:

A small inventory app for a jewelry business wants to calculate the melt value of gold items in stock. Instead of manually updating gold prices each morning, it calls the commodity API and calculates values automatically.

Where to get it: CommodityPriceAPI.com covers metals, energy, agriculture, and more with live and historical data.

$ curl https://api.commoditypriceapi.com/v2/usage \ -H "x-api-key: YOUR_API_KEY"

5. DNS Lookup API

What it does: Lets you query DNS records for any domain: A, MX, TXT, CNAME, NS, and more.

Why developers need it:

Email validation tools (check if the domain has valid MX records)
Security research and threat intelligence
Infrastructure monitoring
Domain verification workflows

Real use case:

A SaaS app lets users connect a custom domain. Before accepting it, the app checks the DNS records to confirm the CNAME is pointing correctly. Manual checking does not scale. An API call does.

Where to get it: WhoisFreaks.com also covers DNS lookup as part of its API suite.

6. Multi-Category API Hub

What it does: One platform. 60+ production-ready APIs across geolocation, domain intelligence, DNS, finance, weather, automation, and utilities.

Why developers need it:

Instead of managing 10 different API providers, 10 different API keys, 10 different billing relationships, and 10 different rate limits, you work with one platform.

This matters more as your app grows.

Real use case:

A developer building a fraud detection tool needs geolocation, WHOIS, DNS, and email validation in one flow. Going to four separate providers adds complexity at every step. A single hub keeps it clean.

Where to get it: APIFreaks.com is an API hub with 60+ APIs across categories. Not a marketplace. Production-ready APIs maintained by the same team.

7. AI Writing and Content API

What it does: Lets you add AI-powered writing and content generation to your app without building a model from scratch.

Why developers need it:

Auto-generating product descriptions
Summarizing long documents
Drafting email responses
Content creation tools for non-technical users

Real use case:

A blog CMS wants to give writers a "generate first draft" button. Instead of integrating raw LLM APIs and handling prompts, tokens, and outputs yourself, a purpose-built writing API handles the complexity.

Where to get it: Netus.AI provides AI content tools with an API layer for developers.

The Bigger Picture

None of these APIs are flashy. None of them go viral on Twitter.

But they solve real problems that real apps run into. And the developers who know about them ship faster, build smarter, and spend less time reinventing the wheel.

The next time you find yourself thinking "I wish there was an API for this," there probably is. You just have not found it yet.

Today’s digital users expect personalized experiences, and if you don’t deliver, someone else will.

Furqan Ashraf — Sun, 17 May 2026 07:44:44 +0000

Personalize or Perish?

Today’s digital users expect personalized experiences, and if you don’t deliver, someone else will.

Studies show that content localization can increase conversion rates by up to 70%.

That’s where ipgeolocation.io steps in. Our IP Location API empowers you to:

✅ Auto-detect a visitor’s country, city, postal code, language, currency, and even time zone
✅ Localize content instantly show prices in €, ¥, or $, display the nearest store, or auto-switch languages
✅ Serve region-specific experiences without ever asking the user to select location or language

Imagine displaying the perfect content for a user in Tokyo, Paris, or São Paulo, all in real time. That’s the power of geotargeting.

Global companies use IP intelligence not just to track but to convert. Because the more relevant the experience, the higher the engagement.

Deliver the right content to the right user at the right time automatically.

Try the IP Location API today: https://ipgeolocation.io/ip-location-api.html

What Is an API Key? Everything You Need to Know Before Using an API

Furqan Ashraf — Mon, 26 Jan 2026 08:27:30 +0000

If you’ve ever tried to use an API and got stuck at the part where it asks for an API key, you’re not alone.

Most beginners hit this wall:
“I understand what an API does, but what is this key thing, and why do I need it?”

Let’s clear that up without jargon, without buzzwords, and without pretending this is more complicated than it actually is.

First: What Is an API (Quick Recap)

An API (Application Programming Interface) is simply a way for one program to talk to another.

Think of it like this:

Your app asks a question
Another service answers with data
The API is the agreed-upon way they communicate

For example, an API might be used by a security tool to pull DNS records for analysis, by a website to check whether a domain exists, or by a weather app to ask for today’s temperature.

APIs are built for machines, not humans. That’s why the responses usually come back as JSON or XML instead of pretty web pages.

So… What Is an API Key?

An API key is a unique string of characters that tells an API that:
“This request is coming from someone who’s allowed to be here.”

That’s it.

It’s not encryption by itself. It’s basically an ID badge for your app or project.

Example of what an API key might look like:

1f9ba190-c513-471b-a573-b8d008bb52fe

When your app sends a request, it includes this key. The API checks it and decides whether to allow or deny access.

The Simplest Analogy (That Actually Works)

Imagine a restaurant:

Menu : the API (what you’re allowed to ask for)
Waiter : the API endpoint handling your request
Kitchen : the server/database
Membership card : the API key

Anyone can look at the menu. But only members can place certain orders.

Your API key proves you’re a member.

Why APIs Use Keys in the First Place

You might wonder:
“Why not just make everything public?”

Some APIs do; those are called keyless APIs. But most don’t, for a few important reasons:

1. Abuse prevention

Without API keys, there would be nothing stopping anyone from sending unlimited requests, scraping massive amounts of data, or deliberately overloading the system. This kind of unrestricted access can quickly lead to abuse, performance issues, and higher operational costs for the API provider.

2. Usage tracking

API keys allow providers to track how many requests each user or application is making, apply rate limits to prevent excessive usage, and offer different pricing tiers based on consumption. This helps API owners manage resources fairly while scaling access for different types of users.

3. Access control

Some data exposed through APIs is paid, sensitive, or intentionally limited to specific use cases. This might include proprietary datasets, security-related information, or resources that should only be accessed under certain conditions or agreements.

API keys make sure only approved users get access.

API Keys vs Passwords (Important Difference)

People often say:

“An API key is just a password.”

That’s kind of true, but incomplete.

Key differences:

API keys usually identify a project or application, not a person
They’re meant for machine-to-machine communication
They often have restricted permissions

This is why API keys should always be treated as sensitive credentials. Exposing them in frontend code or committing them to public GitHub repositories can allow anyone to misuse your API access, potentially leading to abuse, unexpected costs, or even account suspension.

How API Keys Are Usually Used

Most APIs expect the key in one of these places:

HTTP headers
Query parameters

Example (header-based):
Authorization: Bearer YOUR_API_KEY
The exact format depends on the API, which always checks the documentation.

Real-World Examples of DNS APIs and API Keys

Let’s make this concrete.

If you’re working with DNS data, things like:

DNS records
Domain history
Infrastructure changes

You’re dealing with data that needs control and monitoring.

Platforms like WhoisFreaks.com and APIFreaks.com provide DNS APIs that require API keys.

Why DNS APIs require keys

Because DNS data is often used for security investigations, threat intelligence workflows, infrastructure mapping, and abuse detection, it needs to be protected from misuse. Unrestricted access to this kind of information could expose sensitive infrastructure details or enable malicious activity.

An API key ensures that you are an authorized user whose requests are rate-limited and usage is tied to your account.

For example:

WhoisFreaks.com DNS APIs can help you programmatically analyze DNS-related domain information

APIFreaks.com DNS API lets developers query DNS data as part of a unified API platform

In both cases, the API key is what unlocks that access.

How Do You Get an API Key?

Usually, the process looks like this:

Sign up on the API provider’s website
Go to the developer dashboard
Generate an API key
Copy it and store it securely

Some platforms allow multiple keys, key rotations, and permission scopes.

All good signs of a well-designed API.

Final Takeaway

If you remember only one thing, remember this:

An API is how software talks to software. An API key is how the API knows it can trust you.

That’s it.

Once this clicks, working with APIs becomes much less intimidating, whether you’re pulling DNS data, weather info, or anything else.

FAQs: Common Questions About API Keys

Is an API key the same as OAuth or a token?
No. An API key is a simple identifier used to allow access and track usage. OAuth and access tokens are more advanced authorization mechanisms designed for user-level permissions, delegated access, and higher security scenarios.

Can I share my API key with others?
You generally should not. Sharing an API key means sharing your usage limits, billing, and permissions. If someone misuses it, the responsibility usually falls on the key owner.

Where should I store an API key safely?
API keys should be stored in environment variables, server-side configuration files, or secret managers. They should never be hardcoded into frontend code or exposed in public repositories.

What happens if my API key is leaked?
If an API key is exposed, revoke it immediately and generate a new one. Most platforms allow you to rotate keys to minimize damage without downtime.

Do all APIs require an API key?
No. Some APIs are keyless and publicly accessible, especially for non-sensitive or open data. However, most production APIs require keys to prevent abuse and manage access.

Can I use one API key for multiple projects?
You can, but it’s usually not recommended. Creating separate API keys per project makes monitoring, limiting, and revoking access much easier.

Last Advice:

If you still feel unsure about API keys after reading this, that’s normal. Once you start using one in a real request, the concept usually clicks very quickly.

APIs Power Almost Everything You Build. Here’s Why That Matters

Furqan Ashraf — Mon, 22 Dec 2025 12:36:08 +0000

If you’ve built any modern application recently, you’ve already relied on APIs—probably without even thinking about it.

Sending an email?
Checking a user’s location?
Fetching weather data, DNS records, screenshots, or currency rates?

All of that happens through APIs.

APIs quietly do the heavy lifting behind the scenes. They connect services, move data, and let developers build complex systems without reinventing the wheel. In this article, I’ll break down why APIs matter so much today, what developers actually need from them, and how a unified API platform like APIFreaks fits into real-world development workflows.

Why APIs Are So Important Today

Modern software isn’t built as a single, isolated system anymore. It’s a collection of services working together.

APIs make this possible.

Instead of building everything from scratch, developers use APIs to:

Automate workflows
Pull real-time data
Integrate third-party services
Scale applications faster

For example:

A SaaS app might use a DNS API to monitor domains
A security tool might rely on WHOIS or IP data
A monitoring service might need screenshots of web pages
A dashboard might pull weather or currency data in real time

Without APIs, all of this would be slower, more expensive, and harder to maintain.

The Real Problem Developers Face With APIs

APIs are powerful, but using too many different providers creates friction.

Most developers run into the same issues:

Different API styles and response formats
Separate dashboards and billing systems
Inconsistent documentation quality
Multiple API keys to manage
Extra time spent just on integration

Instead of focusing on building features, you end up managing vendors.

That’s where a unified API approach becomes useful.

What Developers Actually Need From an API Platform

From a developer’s perspective, a good API platform should:

Be easy to integrate
Have consistent request/response structures
Offer reliable uptime
Cover multiple use cases
Provide clear documentation
Scale as your product grows

You don’t want ten APIs from ten vendors when one well-designed platform can do the job.

Introducing APIFreaks: One Platform, Multiple Developer APIs

APIFreaks.com is designed around this exact problem.

Instead of chasing different providers, APIFreaks brings multiple commonly used APIs into a single, developer-friendly platform.

It offers APIs for:

DNS lookup
WHOIS data
IP intelligence
Website screenshots
Weather data
Currency and commodity data

All APIs follow a consistent structure, making integration simpler and faster, especially if you’re building SaaS products, security tools, or automation workflows.

A Quick Example: DNS Lookup API in Action

Let’s look at a simple Python example using the DNS Lookup API from APIFreaks.

This example fetches DNS records for a domain, which can be useful for monitoring, security analysis, or troubleshooting.

Python Example

pip install requests

import requests 

url = "https://api.apifreaks.com/v1.0/domain/dns/live?host-name=example.com&type=all"

payload = {}
headers = {
    'X-apiKey': 'API-KEY'
}

response = requests.request("GET", url, headers=headers, data=payload)

print(response.text)

With a single request, you can:

Inspect DNS records
Track configuration changes
Detect misconfigurations or suspicious updates
Automate domain monitoring tasks

This is the kind of task that would otherwise require custom scripts or multiple tools.

Real-World Use Cases

Here’s how developers are using APIs like these in practice:

SaaS Platforms

Automate domain checks, DNS monitoring, and IP intelligence as part of onboarding, analytics, or security workflows.

Cybersecurity Tools

Combine DNS, WHOIS, and IP data to detect suspicious infrastructure and risky domains early.

DevOps & Monitoring

Track DNS changes, capture website screenshots, and monitor uptime using API-driven automation.

Internal Tools & Automation

Build internal dashboards that pull real-time data without manual intervention.

APIs Are the Building Blocks of Modern Software

APIs aren’t just integrations, they’re core building blocks of modern applications.

When you choose the right API platform, you:

Build faster
Reduce complexity
Scale more easily
Spend more time on real product development

A unified platform like APIFreaks helps keep your architecture clean and your integrations manageable, especially as your project grows.

If you’re building something that relies on external data or automation, APIs aren’t optional anymore, they’re essential.

Fraudsters Can't Hide Anymore. Here's How to Spot Them.

Furqan Ashraf — Thu, 14 Aug 2025 15:13:40 +0000

When a user or customer claims to be in London but their IP location shows Lagos, that's a red flag. In the world of e-commerce and online platforms, these inconsistencies are often the first sign of fraud. The ability to spot and block these fake users in real time is no longer a luxury; it's a must.
This guide will show you how to integrate IPgeolocation.io's IP Security API to get real-time threat intelligence, allowing you to spot fraud before it happens and build a more secure platform.

The Threat Intelligence You Need, Instantly

The IP Security API goes beyond simple location data. It provides a full list of threat intelligence, giving you a complete picture of who is interacting with your platform and whether they're a potential risk.

Threat Scoring: The API gives a risk score from 0 to 100. This score is measurable, so you can instantly check a user's risk level and build rules around it.

Anonymizer Detection: Stop fraudsters from using common tricks. The API can detect if an IP is associated with a VPN, a proxy, Tor usage, or a known bot.

Provider Details: Get specifics on the hiding tool, including the proxy type (e.g., residential, data center) and the provider's name (e.g., NordVPN).

Detailed Data: For a full view, the API adds to its threat data with detailed geolocation, ASN, and ISP/company information.

Up-to-Date Network: The API is backed by an always-updated global IP information network, making sure you're always using the latest details to protect your users.

Putting It to the Test: A Code Example

Let's look at a quick example using Python to show how easy it is to integrate the API into your work. This script will check a given IP address for a security threat and print the results. You can easily change this to fit your specific application's needs.

Input
This is the Python script used to make the API call. The IP_ADDRESS variable is set to a known Tor exit node to show how the API identifies a security threat.

import requests

# Replace with your actual API key from Ipgeolocation.io
API_KEY = 'YOUR_API_KEY'

# The IP address to check.
IP_ADDRESS = '85.239.127.126'

# The API endpoint for IP geolocation and security data
URL = f'https://api.ipgeolocation.io/ipgeo?apiKey={API_KEY}&ip={IP_ADDRESS}&security=1'

def check_ip_threat(ip_address):
    """
    Checks an IP address for security threats using the IPgeolocation.io API.
    """
    try:
        response = requests.get(URL.replace(IP_ADDRESS, ip_address))
        response.raise_for_status()  # Raise an exception for bad status codes (4xx or 5xx)

        data = response.json()

        print(f"--- IP Security Report for {ip_address} ---")
        print(f"Country: {data.get('country_name', 'N/A')}")
        print(f"City: {data.get('city', 'N/A')}")
        print(f"ISP: {data.get('isp', 'N/A')}")
        print("-" * 35)

        security_data = data.get('security', {})
        if security_data:
            print(f"Threat Score: {security_data.get('threat_score', 'N/A')}")
            print(f"Is VPN: {security_data.get('is_vpn', False)}")
            print(f"Is Proxy: {security_data.get('is_proxy', False)}")
            print(f"Is TOR: {security_data.get('is_tor', False)}")
            print(f"Is Bot: {security_data.get('is_threat', False)}")
            print(f"Provider: {security_data.get('proxy_provider', 'N/A')}")
        else:
            print("Security data not available for this IP.")

    except requests.exceptions.RequestException as e:
        print(f"An error occurred: {e}")
    except ValueError as e:
        print(f"Error parsing JSON response: {e}")

if __name__ == '__main__':
    check_ip_threat(IP_ADDRESS)

API Response
This is a sample of the JSON response you would receive from the ipgeolocation.io API for the IP address 85.239.127.126. Notice the high threat_score and the is_tor: true flag, which indicates that this IP is a security risk.

{
  "ip": "85.239.127.126",
  "location": {
    "continent_name": "Europe",
    "country_name": "Germany",
    "city": "Frankfurt am Main"
  },
  "network": {
    "asn": {
      "organization": "Server-Service"
    },
    "isp": "Server-Service"
  },
  "security": {
    "threat_score": 90,
    "is_tor": true,
    "is_proxy": false,
    "proxy_type": "TOR",
    "proxy_provider": "",
    "is_anonymous": true,
    "is_known_attacker": false,
    "is_spam": false,
    "is_bot": false,
    "is_cloud_provider": false,
    "cloud_provider": ""
  },
  "time_zone": {
    "name": "Europe/Berlin"
  }
}

Real-World Use Cases

The IP Security API provides security that scales with your platform. Here’s how you can implement it:

E-commerce: Use the API in your checkout process. If a high risk score is found or a user is on a known proxy, you can flag the transaction for a closer look or block it to stop payment fraud.

Fintech: During user sign-up, implement the API to check a user's location and connection type. This helps with confirming who the user is and spotting suspicious new accounts.

SaaS Platforms: Prevent bots from creating fake accounts. By checking the is_threat or is_bot flags during sign-up, you can greatly reduce spam and keep your data clean.

Conclusion

IP information is a powerful set of tools for your security. By integrating the IP Security API, you move from handling fraud after it happens to a forward-thinking, real-time security model. It's a simple, effective way to get deep insights into your users and protect your platform from a wide range of threats.
Ready to get started? Sign up for your Free API Key and secure your platform today.