Is it worth building your own MAC vendor lookup, or running ours?

Every MAC vendor lookup starts the same way: download an OUI file from IEEE, write a parser, ship it. That part really is a weekend project. What isn't is everything downstream of it once that lookup sits in a live path: a device onboarding flow, a network access control decision, a fraud signal, something that has to answer correctly, quickly, and without falling over, on every request, indefinitely. That's the part we've spent our time on, and it's the part we're offering you a shortcut around.

What's actually hard about this

None of it is exotic. All of it is tedious to get right, and easy to get subtly wrong:

• IEEE publishes five separate registries, not one: MA-L, MA-M, MA-S, IAB, and CID, three different block sizes (24, 28, and 36 bits) with overlapping prefixes. A lookup has to do longest-prefix matching across all three, correctly, or it misattributes every MA-M and MA-S block to whatever MA-L organization happens to share its top three octets.
• The data changes continuously, not on a release cycle. New blocks get assigned, organization names get corrected, addresses get updated. A parser that runs once at build time is stale the day after you run it.
• Doing that refresh without hammering IEEE's servers, or your own, means conditional requests, tracking an ETag per registry, and rebuilding derived files atomically so nothing serves a half-written result mid-update.
• Input arrives in every format people actually type: colons, dashes, dots, no separator at all, mixed case. Normalizing that reliably, across every code path that touches a MAC address, is its own small minefield.
• A correct answer is more than a vendor name. Whether an address is locally administered, whether it looks like a privacy-randomized address and how confident that judgment actually is, its IEEE 802c SLAP quadrant, its derived EUI-64/IPv6 form: real analysis, not a CSV join.
• And then it has to hold up. Indexed for fast longest-prefix lookups, not a linear scan; cached where caching is safe; correct under concurrent writes while a sync job is mid-refresh. Fine at ten requests a day. A different problem entirely at production QPS.

Individually, none of this is hard. Together, kept correct, kept current, and kept fast, it's a real system, not a script.

Why build it when you can install it

We built that system already, and we run it ourselves, in production, for the hosted API and website. The self-hosted license is that same engine, packaged as a .deb and installed on your own infrastructure:

sudo dpkg -i macadress_<version>_amd64.deb
sudo systemctl enable --now macadress-syncd macadress-api

Two binaries: a sync engine that keeps IEEE's registries current on your own schedule, and the same lookup API we serve publicly, answering entirely on your hardware. No third-party API in the request path, no per-query billing, no rate limit but your own. Every lookup, and every MAC address it touches, stays inside your network.

Is it worth it?

Honestly, not always. If you look up a handful of addresses a month, our free JSON API or a plain CSV download is all you need, and self-hosting would just be maintenance you didn't have to take on. Self-hosting earns its cost when the lookup sits on a path that can't leave your network, needs to survive real load without a rate limit, or has to keep working with zero external dependencies at all: air-gapped environments, compliance-sensitive networks, or a product where this lookup is a core feature, not a side query.

In those cases, the honest comparison isn't the price of a license against the price of a CSV parser. It's the license against the engineering time to build the same correctness and the same headroom yourself, and then the ongoing time to keep both current as IEEE's data and your own traffic keep changing. That second part doesn't show up on day one. It shows up every quarter after.

What's included

• Unlimited local queries, no rate limit but your hardware's
• The same sync engine we run, on your own schedule
• Scheduled IEEE registry updates, so the data doesn't go stale after install
• Installable via .deb, fits air-gapped and offline environments

See the full breakdown, and current pricing, on the pricing page, or get in touch if you want to talk through whether it fits before buying.