A New Blog, Built In-House

If you've visited our blog in the last day or so you may have noticed that it looks a little different. That's because the blog is now running on software we wrote ourselves, replacing the third-party blogging platform we had been self-hosting until now.

We want to explain why we did it, because the reason is tied to a very busy Wednesday.

About those PHP CVEs

On Wednesday, PHP had two major CVEs published: CVE-2026-109618 and CVE-2026-109619. When vulnerabilities of that size land in the language that powers our platform, we treat it with urgency.

We updated our entire platform to the latest version of PHP, which includes fixes for both of these vulnerabilities, and we had it rolled out everywhere within 20 minutes of the patched PHP version being available. Our API servers, our dashboard, our website, all of it. That speed in updating is because with a service like ours, sitting on a known vulnerability is not something we can do.

However..

The third-party blogging software we were using was not compatible with the latest version of PHP. We had a choice to make: hold back PHP on the blog's hosting just for the sake of one piece of software, or take the blog offline, we took it offline initially while we planned what to do.

Running an outdated and vulnerable version of PHP for our blog was never going to happen, so we took that option off the table immediately. That left us with two choices. We could take the third-party software and modify it ourselves until it worked on the latest version of PHP, or we could replace it with something else.

Patching someone else's code means we would own the compatibility work for software we didn't write, we'd have to repeat that work every time PHP moved forward, and we'd still be left with all of the features and code paths we never wanted in the first place. So we decided to replace it.

Why Less Is More

The new blog software does only two things: it displays posts, and it lets you page through our database of posts. That's it.

There's no login system, no admin panel, no comments, no plugins, no theme engine and no user accounts. There's nothing on the page that accepts input and nothing for an attacker to authenticate against, because there's nothing to log in to. If a feature doesn't exist, it can't have a vulnerability.

This is the same philosophy we apply to the rest of our infrastructure. Every feature is attack surface, so we've kept the blog as small as it can possibly be. It also means we can maintain it ourselves, understand every line of it, and keep it compatible with new PHP releases the moment they arrive instead of waiting on someone else to do so.

What About WordPress?

We did consider the obvious option of WordPress, and we want to be upfront about why we ruled it out.

WordPress is a capable piece of software and it powers a huge portion of the web, but that popularity cuts both ways. It has an enormous feature set, a sprawling plugin and theme ecosystem, user management, an admin dashboard, XML-RPC, a REST API and much more. Every one of those is part of an attack surface that is simply too broad for us.

Vulnerabilities in WordPress and its plugins are discovered constantly, and attackers actively scan for installations they can exploit. For a typical website that's a risk you manage with diligent patching. For us it's a risk we're not willing to take on at all, because the blog lives on the same infrastructure as our core service. We would never be comfortable hosting WordPress alongside the systems that serve your API requests, and since we don't believe in compromising on that, WordPress was never really a candidate.

Basic On Purpose But better Over Time

The new blog is very basic, and that's exactly what we wanted, simple and secure.

But basic doesn't have to mean plain. The blogs apperance will evolve over time as we add features that improve the reading experience, we won't however be adding in features like comments, plugins or admin portals which invite vulnerabilities.

What This Means For You

For readers, nothing about how you use the blog changes. You can still browse our posts and page through older ones just like before. If you spot anything that looks out of place after the switch, please get in touch and we'll take care of it.

What you do get however is a blog that loads a lot faster due to its basicness, more reliable in loading individual posts (which was a bit hit or miss previously) and most importantly secure.

Thanks for reading and have a wonderful weekend!

Back in March we wrote about how we were tackling residential proxy detection with a new rules-based system in our address collector. Since then we've kept building on it, and today we want to share two changes that came out of that work: much shorter listing times for the addresses we see most, and a new Caching Guidance section in our API documentation.

3.4 Million Residential Addresses, Every Hour

We're now collecting 3.4 million residential proxy addresses every hour. That's a big number, but the number alone isn't what matters. The challenge with residential proxies has never been only finding the addresses, it's knowing when an address has stopped being a proxy and a normal person is using it again.

Residential proxy services route their customers through ordinary home and mobile connections. Those addresses change hands constantly, either because an ISP's dynamic pool reassigns them or because the address is shared by many real users at once through technologies like CG-NAT. An address that was a proxy a few minutes ago might now be a family streaming a film. Listing it for too long means blocking those people.

Listing Times as Low as 60 Seconds

For some of these addresses we now expire the data in as little as 60 seconds. The exact time depends on a lot of factors, including how frequently residential proxy companies hand us that address and how many legitimate users are likely sharing it through CG-NAT.

The principle behind it is simple. The addresses we see most often get the shortest listing times, because we're constantly refreshing them. If an address really is still operating as a proxy, we'll see it again almost immediately and it will be re-listed, so there's no need to hold on to it for long.

The addresses we see less often get longer listing times, but within reason. These are based on factors like the long-term abuse history of the address. For example:

• An address we can successfully use as a proxy server once every day over the past 90 days may get listed for several hours, because it clearly has a long-running pattern of abuse and we simply aren't handed it very often.
• An address we can use every 30 minutes may only be listed for 45 minutes each time, because we'll know very quickly if it stops acting as a proxy server.

Every Address Is Treated Uniquely

None of this is a blanket setting. It's a per-address optimisation, so every address gets its own listing time based on its own history rather than a one-size-fits-all rule for a range, an ISP or a proxy operator.

The result is that we can mark addresses as clean much sooner after they stop operating as a proxy, which means fewer false positives for your legitimate users, while the addresses with a long record of abuse stay listed for as long as they need to be.

As with our previous listing changes, this is a backend change to how long we display positive detections, so it's live now for all our v1, v2 and v3 API versions.

Introducing Caching Guidance

Shorter listing times only help if your own systems respect them. Over the years we've seen a pattern where a customer queries our API, receives a positive detection, and then caches that result for far longer than the detection is actually valid. The address may have been delisted by us after a few minutes, but the customer's cache keeps treating it as a proxy for hours or days, and a real user ends up blocked through no fault of their own.

To help with this we've added a new section to our API documentation called Caching Guidance. It gives guidance on how long you should be caching our data, with a particular focus on avoiding false positives caused by caching positive detections for too long. If you cache our results in any way, whether in a database, Redis, a CDN or your application's memory, we'd encourage you to give it a read and compare it against what your integration does today.

You can find it on our API documentation page.

Our work on residential proxies continues!

This is the latest in several blog posts we've authored on the subject of residential proxies and as we wrote in our 10 year anniversary post we truly believe our next decade will be measured on how well we detect and optimise our listing of them. They are our number one focus still and reducing false positives caused by shared and dynamically assigned addresses goes hand-in-hand with the detection of them, it's just as important to us and our customers.

The new listing behaviour is live right now and requires nothing from you. Your results will simply get more accurate as addresses are delisted sooner. The Caching Guidance section is available now in our API documentation. If you have questions about how long to cache our data for your particular use case, please get in touch. We do read and reply to every message.

Thanks for reading and have a wonderful week!

Today the price increases we announced back in August have officially gone live. As we said at the time, our Starter, Pro and two of our lowest Business plans now have new pricing, and we wanted to lay out exactly what's changed, why it happened, and what it means for you.

The New Prices

Here is every plan that has changed, with the old monthly price on the left and the new monthly price on the right.

Our largest Business plan at $99.99 has not changed, and neither have our Enterprise plans at $199.99, $299.99 and $399.99.

Why We Had To Do This

We don't enjoy raising prices, and doing it twice in one year is not something we wanted. But as we explained in our price change announcement post, the cost of computing hardware has climbed to levels we haven't seen before. DRAM and NAND flash pricing has upended the hosting market, our server hosts have passed those increases on to us, and availability of servers has become genuinely difficult on top of that.

That has hit us in two ways. New servers cost far more than they did in prior years, which we saw first hand when we brought Fermi and Kepler online in June. Servers we've rented for years have also had their prices raised, some more than once this year, with more increases expected throughout 2027.

We've set these prices to cover what we expect our costs to be for 2027, so we're not coming back mid-year for another round of increases. Even with these changes we still believe proxycheck.io is the most affordable IP reputation service on the market, and the free plan is unchanged: one thousand queries per day with the exact same data and detection accuracy as every paid plan.

We also looked at what we could do to maintain our lowest priced plan which provides 10,000 daily queries and you'll note it saw the lowest increase in price at 25.1%, this plan is very important to the internet as a whole, not just to our service as a paid entry point, so maintaining its value by only increasing it by a single dollar is an achievement.

And to be clear we thought about halving this plan from 10,000 to 5,000 daily queries to maintain its existing price at $3.99 but we felt that would not be good value, it would drive people to create multiple free accounts (which is against our terms of service) and it would alter our entire range of plans by either introducing new plans or reducing our larger plan sizes to compensate for the lower starting query volume. So ultimately increasing its price by $1 made the most sense.

If You're Already Subscribed, Nothing Changes

This is the most important part of this post, so we'll say it plainly: we do not raise prices on active subscriptions. If you're already subscribed to a paid plan, you will keep paying the price you originally subscribed at for as long as that subscription remains in place. You don't need to do anything.

The new pricing only applies to:

• Customers who start a brand new paid plan.
• Customers who cancel and later start a new plan.
• Customers who upgrade or downgrade an existing plan to a different one.

If you're on a current plan and you're happy with it, simply leave it alone and you'll keep your existing rate.

Pre-Paying For a Year Still Saves You 8.33%

A reminder that this discount has always existed and it's unchanged. When you pay for a plan a year up-front, you pay for 11 months instead of 12, which works out to an 8.33% discount, or in simpler terms one month free. Here's what that looks like on the new pricing:

Where to Find It

The new prices are live right now on our pricing page and in your Customer Dashboard. If you have any questions about your plan, which pricing applies to you, or whether it makes sense to change plans, please get in touch. We read and reply to every message.

Thank you to everyone who's supported us and given us the chance to keep growing the service. Thanks for reading and have a wonderful week!

Today we're shipping a useful addition to both our API and our Lookup page: we now tell you exactly how many times we've observed an address behaving anonymously, and on the Lookup page we're pairing that number with a brand new heatmap so you can see an addresses anonymous activity at a glance.

A New Key: times_seen

On the v3 API (Dated June 2026) this shows up as a new key called times_seen, sitting alongside the rest of the detection data you already get back for an address. It's a simple running count of the number of times we've observed that address behaving in a way that triggered a positive detection.

We added this because risk scores and confidence tell you how dangerous an address looks and how sure we are about it, but they don't tell you how persistent the behaviour has been. An address flagged once an hour ago and an address flagged twelve thousand times over the past year can carry a very similar risk score, but they're not really the same kind of threat, and now you have the data to tell them apart.

We've not issued a new dated API version for this new feature because this data was always already available and parsed internally by the API and we're merely exposing it in the API output making this a minor change.

On the Lookup Page: Observed

The same number appears on our Lookup page under a new field called Observed, sitting right next to the existing Risk Score, Confidence, First Seen, Last Seen, Danger Estimate, Device Estimate and To Be Delisted fields.

A New Detection History Heatmap

The Observed count on its own is useful, but a single total doesn't tell you when the activity happened, and that's the gap we wanted to close next. So alongside it we've added a new Detection History section to the Lookup page, a full year-long heatmap showing how many times we detected the address on each individual day over the past twelve months.

Each column represents a week, each row represents a day of the week (Monday through Sunday), and each little square is shaded according to how many detections we logged that day, the darker and more saturated the color, the more active the address was. Scanning across it, you can immediately pick out the weeks an address went quiet, the days it spiked, and whether the recent activity is part of a long-running pattern or something new.

This matters because raw totals can be misleading on their own. An address observed a thousand times could mean a thousand detections spread evenly over a year, or it could mean nine hundred of them landed in the last two weeks. The heatmap makes that distinction obvious at a glance and as with this IP you can clearly see its abuse is ramping up.

Where to Find It

Both of these are live right now. The times_seen key is available on the API today, and the Observed field and Detection History heatmap are already visible on every result on our Lookup page. No flags or opt-ins are required, if we have detection history for an address, you'll see it.

Thanks for reading and have a wonderful week!

Today, we've once again placed notices on our pricing page and in the customer dashboard to let everyone know that we'll be increasing the prices of our Starter, Pro and Business plans in October 2026. As we did last year ahead of the January increase, we wanted to give everyone a full two-month heads-up.

You're probably wondering why we're doing this again so soon, only a little over seven months after our last increase. The short answer is that computer hardware prices have reached unprecedented levels, and our server hosts are raising their own prices in response, on top of availability problems that are making it genuinely difficult to procure servers at any price, let alone a reasonable one.

This has a knock-on effect such as when we scale the service by bringing on new servers, as we did in June with Fermi and Kepler we're seeing much higher prices than we did in prior years for new hardware. We're also running into mid-cycle price rises too as servers we've rented for years are going up in cost, and some of the servers we rented more recently have already had their prices raised several times this year with more expected throughout 2027.

Because we don't raise prices on active subscriptions, all of this leaves us with less room to wait it out. We have to move earlier, and a little more aggressively than other services might.

That brings us to where we are today. We've spent a lot of time working through the new pricing and talking it over with some trusted partners. We're not ready to share the actual numbers yet, since they may still shift between now and October, but we can say with certainty that our Starter and Pro plans will be increasing, along with at least two of our Business plans. The largest Business plan, our Enterprise plans, and any custom plans sized beyond those will not be increased.

And as always, if you're already subscribed, nothing changes for you. We never raise the price on an active subscription. The new pricing will only apply if you cancel and start a new plan, or if you upgrade or downgrade an existing plan after the new prices launch in October. That's exactly why we're giving you this much notice: you have time to look at your usage now and decide whether starting a plan, or adjusting the one you already have, makes sense while the current lower pricing still applies.

Like the last time we raised prices, we don't want to be doing this. We still believe we'll remain the most affordable option in the industry, the lowest-priced IP reputation service out there, but DRAM and NAND flash pricing has upended the hosting market in a way we simply can't absorb if we want to keep growing the service. Ordinarily we'd wait until January to make these pricing changes, as we have in the past, but between how quickly we're gaining customers under the current pricing and the cost pressures for both new and our existing servers, two increases in one year have sadly become necessary.

Thanks for reading and have a great week, we'll make a new post in October once the new prices go live.

Turn Off Address Logging With a Single Switch

Starting today, you can disable address logging for your entire account from a single place. Head over to your Customer Dashboard and you'll find a new setting called Address Logging. Switch it off and from that point on, none of the addresses you check with us, whether IPs or emails, get saved anywhere. Each address is used to answer your request and then discarded the instant that request finishes, no address is written to a log, a database, or anywhere else.

Above is a screenshot showing the new toggle positioned below the Main API and Dashboard API access toggles.

The Trouble With Per-Request Flags

Long-time users will know we've offered a way to do this on a per-query basis for years. Supplying &tag=0 with a request to our API tells us not to log that particular check at all, and it still works exactly as it always has. But it has some limitations we wanted to solve.

First, it has to be added to every single request. That's a minor inconvenience if you're calling our API from your own server-side code, but if you're using one of our plugins, a third-party library, or a CMS integration that doesn't give you a way to bolt custom query flags onto the request URL, you simply couldn't use it, the flag had no way to reach us.

Second, &tag=0 only ever worked on requests made to the API itself. If you checked an address directly through our Single Lookup or Batched Lookup pages, there was no request URL for you to add a flag to in the first place, so those checked addresses were always logged somewhere if only briefly.

Third, this helps you with compliance. Some customers really cannot have any addresses logged and they don't want to mistakenly ever have an address logged by us simply because they forgot to send &tag=0. We respect the need for a bulletproof anti-logging feature and that is what this toggle provides.

One Setting, Every Request

The new Address Logging toggle solves all these problems by moving the decision out of the request and into your account. With logging disabled, every address you check is treated the way &tag=0 already treats a single request, except now that applies automatically and everywhere: server-side API calls, the client-side snippets on the CORS tab, our plugins, and both of our web lookup tools. It also takes priority over anything you send in the tag flag itself, so even a request with a descriptive tag attached won't be logged. You don't need to touch a single line of code or a single request URL to benefit from this toggle.

And to be clear, &tag=0 isn't going anywhere. If you'd rather keep logging on generally and just exclude a handful of especially sensitive requests, that flag is still there for exactly that. The new setting is for when you'd rather make the decision once, for your whole account, instead of repeating it on every request.

Worth Knowing Before You Flip the Switch

Disabling Address Logging doesn't change the answers you get back. If an IP address is anonymous, or an email address is disposable, we'll still tell you so, the detection data we hold is unaffected. What changes is purely what we keep about your own account's activity afterwards. Your positive detection log relies on us keeping a record of your positively identified addresses, so with address logging switched off you won't see new entries appear there. If you lean on that data to spot brute-force login attempts or see which pages are taking the most abuse, it's worth keeping that in mind before you switch this on account-wide.

You'll find a little notice like the screenshot above if you've disabled address logging globally to let you know why it's not updating.

Where to Find It

The new Address Logging setting is live right now in your Customer Dashboard. If data minimisation matters to you or your customers, this is the simplest way we offer to accomplish that. You can read more about how and why we handle addresses the way we do on our GDPR compliance page.

This new feature has been implemented across all supported versions of our API which means it works for all v1, v2 (2023+) and v3 requests.

Thanks for reading and have a wonderful week!

Say Hello to Fermi and Kepler, Our Newest Servers

If you've been with us for a while, you'll know that every server in the proxycheck.io network gets a name pulled from space. Today we're welcoming two more members to that family: Fermi, now serving North America, and Kepler, now serving Europe.

Both names are a nod to two scientists whose work still shapes how we look at the universe, and, fittingly, both have NASA space telescopes named after them too. Here's a bit about where the names come from, and why these particular servers matter more than most.

Meet Fermi

Enrico Fermi (1901–1954) was an Italian physicist whose career touched almost every corner of modern nuclear and particle physics. He won the Nobel Prize in Physics in 1938 for his work on induced radioactivity, and a few years later led the team that built the world's first nuclear reactor, achieving the first self-sustaining nuclear chain reaction in 1942. The class of particles called fermions, and the element fermium, are both named in his honour.

NASA's Fermi Gamma-ray Space Telescope has carried his name into orbit since 2008. It scans the sky for the highest-energy light there is, gamma rays, tracking everything from pulsars and supernova remnants to flares from supermassive black holes.

Our new Fermi server is deployed in North America and features AMD's latest Zen 5 architecture.

Meet Kepler

Johannes Kepler (1571–1630) was a German mathematician and astronomer best known for his three laws of planetary motion, which described, for the first time, how planets actually move around the sun in ellipses rather than perfect circles. Working from the painstaking observational data of his mentor Tycho Brahe, Kepler's laws went on to form much of the foundation Isaac Newton later built his theory of gravity on.

NASA's Kepler Space Telescope carried that legacy forward from 2009 to 2018, staring at a single patch of sky and watching for the tiny brightness dips caused by planets passing in front of their stars. It's responsible for confirming thousands of exoplanets, and for fundamentally changing how we think about the prevalence of other worlds.

Our new Kepler server is deployed in Europe, and also features AMD's latest Zen 5 architecture.

Why these two servers are special

Fermi and Kepler aren't just new additions, they're currently the most powerful servers in our entire fleet, built on AMD's latest Zen 5 architecture with plentiful DDR5 memory and PCIe 4.0 NVMe drives, like all our other server nodes these are bare metal servers, we do not share their resources with any other tenants which guarentees performance and security.

Now we do want to discuss the less than glamorous reason we brought these two servers online now rather than next year when we intended to refresh all our server hardware:

• DRAM and NAND flash storage prices have been climbing noticeably, and the trend doesn't look like it's reversing any time soon.
• Server availability from our datacenter hosts has been drying up fast, with lead times stretching out and stock becoming harder to secure.

Put those together, and the risk became clear: even though we didn't strictly need Fermi and Kepler online today, we could see a real possibility of needing that capacity in 2027 and simply not being able to get our hands on it when the time came. Rather than gamble on availability and pricing one-to-two years from now, we decided to secure our own supply early while we still could.

What this means for you

In practical terms, this means more headroom, more redundancy, and faster responses across North America and Europe as traffic continues to grow. As always, our full server status and locations are visible on our service status page, so you can see all our nodes and their health status.

Thanks for reading and have a wonderful weekend!

v3 API Goes Stable: The Beta Tag Comes Off

Ten months ago we launched an open beta of our v3 API and as of today, the v3 API is officially out of beta and is now our new stable API.

Before we get into what's changed, we want to say thank you. A beta is only as good as the people willing to use it before it's finished, breaking things, filing reports and rebuilding their integrations against a target that kept moving. Many people did exactly that for the better part of a year, and v3 is a far better API for it.

A Quick Look Back

We introduced the v3 beta back in August 2025, and since then we've shipped several major beta releases, each one chipping away at rough edges like the output format and adding new capability:

• August 2025: First beta with a brand new output format featuring nested categories and a new detections array.
• October 2025: Timestamps moved to the ISO 8601 format making them both machine and human readable without sacrificing per-second accuracy.
• November 2025: Confidence scores arrived, alongside first_seen and last_seen timestamps for every detection.
• February 2026: detection_history and attack_history became permanent fixtures of every response, and the operator section gained services and additional_operators.
• May 2026: A full OpenAPI v3.1.0 specification was published, covering both the v3 API and our Dashboard APIs.

Each release was a stepping stone, and today's stable version is all of that put together, polished, with an output format that can take us into the next decade.

What Actually Changed From v2

If you haven't been following the beta closely, here's the short version of what makes v3 a genuinely different API rather than just a version number bump.

Everything is nested and consistent. Instead of a flat list of fields that may or may not appear, you now get clearly organised sections: network, location, operator, and detections. Every section is always present. If we have nothing to tell you, you'll get a null rather than a missing key, so your code never has to guess whether a field exists at all.

Booleans instead of strings. No more checking if a string equals "yes". Proxy, VPN, TOR, hosting and the rest of our detections now return true or false, the way they always should have.

Multiple detections at once. An address can now be flagged as a VPN and a scraper and have a history of compromise simultaneously, rather than forcing a single label onto an address that's clearly doing more than one thing.

A far fuller response by default. Almost every query flag from v2 has been retired because v3 simply gives you the full picture without you needing to ask for it piece by piece. This lets us optimise for always generating a full result which improves cache hit rates and lowers response times for every request.

Real HTTP status codes. Denied and failed requests now come back with proper 401, 403, 429 and 400 codes instead of a 200 OK hiding a denial in the body of the response, so your monitoring and error handling can finally behave the way you'd expect from a modern API.

Confidence scores alongside risk scores. Risk tells you how dangerous an address looks. Confidence tells you how sure we are about the detection behind that score. Used together they let you build far more nuanced rules than a simple yes or no ever could.

Detection history and attack history as standard. You can now see whether a positive detection is still live or has been delisted, and exactly when, plus a clean breakdown of the kinds of attacks an address has been involved in.

Deeper operator intelligence. Knowing an address belongs to a VPN is useful. Knowing which VPN, what services that operator provides, and which other operators have also been seen running the same address is a different level of useful entirely, and that's exactly what the expanded operator section now gives you.

Smoother under load. On top of all the format changes, v3 is also simply faster and steadier at scale, with noticeably less jitter between responses when you're sending large volumes of requests.

What This Means If You're Still On v2

Nothing changes for you today, and nothing has to change for a very long time. We are committed to supporting the v2 API until 2035.

We mean that. There's no countdown clock hidden in the fine print and no plan to quietly nudge you off it before then. If v2 is doing its job for your application, keep using it. The same servers, the same reliability and the same support still backs it.

What going stable does mean is that v3 is no longer a moving target. The structure you build against today is the structure you'll be working with for the long haul, which is exactly the kind of stability you want before committing a production system to a new API version.

If you've been holding off starting a new integration until v3 settled down, or you're planning one now, this is a great time to make the move.

Getting Started

• Point your requests at the v3 endpoint. No version flag required, you'll automatically receive the latest stable release.
• Select Latest Stable Version from the version dropdown in your Customer Dashboard if you'd rather pin it explicitly.
• Read through the full API documentation for every field, flag and response type.
• Import our OpenAPI specification into Postman, Insomnia, Swagger UI or your code generator of choice.
• Take it for a spin in the test console before spending a single query against your daily allowance.

We genuinely couldn't have gotten v3 to this point without the people who used it while it was still in beta, filed the issues, asked the awkward questions and told us when something didn't sit right. Thank you, sincerely.

Here's to a stable v3, a supported v2, and another decade of keeping the internet a little more honest.

Thanks for reading and have a wonderful week!

One of the most consistently requested things from developers integrating our service into their software has been an OpenAPI specification and today we're happy to say that wait is over. We've published an OpenAPI v3.1.0 specification covering both our v3 API and our Dashboard APIs, and it's available right now from our API documentation page.

Why Now?

With our v3 API preparing to leave open beta and become our new stable API, this felt like exactly the right moment to ship the spec. We wanted it in place before v3 goes stable so that developers building integrations from day one have a machine-readable description of the API to work with rather than hand-rolling clients purely from written documentation.

It has been one of the most frequently requested things we've heard from users over the years, and we're glad we were finally able to prioritise getting it done properly. Producing a spec for an API that's still in active development is a balancing act, but we felt the timing was right. The v3 API has now gone through several substantial beta releases and its structure has settled considerably.

What's Covered?

The specification covers both major surface areas of our API offering:

The v3 API
Our new-generation proxy, VPN and threat intelligence API. This includes IP and email address checking, the full response schema (network data, location, detections, risk scores, confidence scores, operator information, detection history, attack history and more), query flags, and all status and error response formats.

The Dashboard APIs
The full suite of programmatic dashboard controls, including positive detection exporting, tag exporting, account usage and query volume exporting, custom list manipulation (add, remove, set, clear, erase), custom rule management (print, enable, disable), and CORS origin list management.

All of this is described using the OpenAPI v3.1.0 format, which is the current specification version and brings full alignment with JSON Schema, meaning you can use the spec directly with any modern tooling that supports it.

What Can You Do With It?

Having a formal OpenAPI spec opens up a lot of practical possibilities for developers:

• Generate a client library in your language of choice using tools like openapi-generator or Speakeasy. If your language isn't yet represented in our code libraries, this is the fastest path to a typed, fully featured client.
• Explore the API interactively by importing the spec into Swagger UI, Scalar, or Stoplight — useful for understanding the response schemas before you write a single line of code.
• Import it into Postman or Insomnia and have a ready-made collection of every endpoint, with example request parameters and expected response shapes already filled in.
• Validate your integration by using the spec to confirm that your code is constructing requests correctly and handling all documented response fields.
• Stay up to date — as the v3 API evolves post-beta we'll be keeping the spec in sync with the documentation, so you'll always have an authoritative reference.

Where to Find It

The spec is documented and available for download from the OpenAPI Spec section of our API documentation found here.

A Note on the v3 API Beta

For those who haven't been following the v3 beta, our v3 API is a significant overhaul of how we present data. It moves to a fully nested JSON structure, returns booleans instead of yes/no strings, always includes a rich set of detection data without requiring individual query flags, introduces proper HTTP status codes for denied and failed requests, and adds new sections like detection_history and attack_history. It also brings a confidence score alongside the risk score, giving you finer-grained control over how aggressively you act on detections.

If you're currently on v2, there's no rush. We're committed to supporting the v2 API for at least until 2035. But if you're starting a new integration, v3 is where you want to be, and the OpenAPI spec is the best place to start.

As always, if you have any feedback — on the spec, the API, or anything else — please get in touch. We do read and reply to every message. Thanks for reading and have a wonderful week!

Ten years ago, proxycheck.io opened its doors with a single purpose: give developers and website operators a fast, reliable way to detect proxy and VPN traffic. A lot has changed since then, but our purpose hasn't.

We started as a simple API, just a single page service and completely free. Today, proxycheck.io is a globally distributed, multi-region detection platform fielding billions of queries every month for customers ranging from solo developers running hobby game servers to enterprise businesses protecting their platforms at scale. This birthday post is a chance to look back at how we got here, celebrate what we've built, and share our sincere thanks towards all our customers.

The world we launched into

When proxycheck.io launched, the proxy landscape looked very different. The overwhelming majority of proxied traffic ran through free, open proxy servers — poorly maintained machines with forwarded ports, scraped from lists updated every few hours. Detection was a relatively straightforward cat-and-mouse game: collect the IPs, publish a list, update it regularly.

Ten years on, that world is gone. The rise of residential proxy networks - services that route traffic through millions of ordinary consumer devices using mobile broadband and home broadband connections - has fundamentally changed what detection means. You can't just block a datacenter range anymore. You're contending with addresses that look, to every other system, exactly like a real home user in a real city. Keeping up with that shift is perhaps the defining technical challenge of our second decade.

A timeline of the last ten years

2016 - Service launches with the v1 API

2017 - Inference engine added and honeypots

2018 - v2 API ships; bulk IP checking is added with a new API format

2019 - Risk scores, attack history & custom rules introduced

2020 - CORS support & North American infrastructure goes live

2021 - VPN operator cards; dark mode dashboard; Asian infrastructure goes live

2022 - Postcodes added to the API; HA improvements; Unified Changelog;

2023 - Timezone & currency data added to the API

2024 - New status page; device estimates and hostnames added to the API; Account Activity Log;

2025 - v3 API beta begins; confidence scores are added;

2026 - 100 times improvement in residential proxy coverage; detection history added; 10th birthday

And alongside those major features we redesigned many things, the dashboard saw lots of love, the web interface, the lookup pages, our API documentation and the site in general with our light/dark glass themes and navigation bar.

Milestones we're proud of

2019: Custom Rules We gave customers the ability to write their own logic on top of our API. Whether whitelisting cloud gaming services, blocking specific VPN operators or entire nations this feature lets you do it all. This feature that started with just 3 rules allowed per account has grown to become one of the most popular features we offer, in-fact thouands of accounts have created or imported at-least one rule each. This was such a monumental feature for us as it was extremely complicated to implement and took a massive amount of engineering effort.

2020: First servers outside Europe For the first three years, every request routed through our European infrastructure. The launch of our North American cluster was a milestone: suddenly customers in the Americas saw dramatically lower latency, and we had real geographic redundancy for the first time. This was a big monetary commitment to invest in our potential growth and acquire more customers in North America, it did pay off and we've since expanded our infrastructure there twice aswell as adding servers in Asia.

2021: VPN Operator Cards Rather than just returning "VPN: yes", we began telling customers which VPN operator controlled an address, with rich metadata they could build real logic around. The operator intelligence in our new 2026 v3 API - including cross-operator detection and specific service classification - is a direct evolution of this original idea.

The thing we've never changed

Across every API version, every server upgrade, and every pricing revision, one thing has stayed constant: our free plan. One thousand queries per day, with full access to the exact same data and detection accuracy as every paid plan. No degraded results, no watermarked data, no bait-and-switch.

We've also kept something else consistent: our pricing philosophy. When we raise prices - as we did for the first time in six years this past January - existing subscribers kept their existing rate. Loyalty is rewarded here, not penalised. The price you initially subscribed at is the price you pay until that subscription is changed or cancelled.

Thank you, truly.

None of this exists without the people who trusted proxycheck.io early - the platform operators who integrated us into their first Minecraft servers, their early WordPress blogs, their website authentication systems. The developers who wrote libraries, plugins and applications that integrated our API. The customers who sent us bug reports and feature requests. You all made this service what it is and we won't ever forget that.

Ten years. Here's to the next ten, thanks for reading and have a wonderful week.