ssid.aiAPI

ssid.ai vs macaddress.io

Both turn a MAC address into a manufacturer name from the IEEE registry. Pick macaddress.io if you want the vendor table as a file: it sold JSON, XML, CSV and Cisco vendorMacs.xml downloads and its lookup flagged virtual-machine prefixes. Pick ssid.ai when you need the lookup to keep answering and to answer with more than a name: it is free without a key at any daily volume, and it carries router default logins, a compliance dataset and an MCP server. One fact sits over the whole page: macaddress.io has failed every one of our 44 logged fetches between 2026-08-13 and 2026-10-24: 29 came back as a Cloudflare error code, the other 15 returned no HTTP response at all. Those fetches span 73 calendar days, so 29 days inside the span went unfetched and are not claimed as checked. The record, and its limits, are below.

Last updated 2026-10-24 · macaddress.io product facts quoted from their homepage as archived 2026-08-07

Side by side

ssid.aimacaddress.io
ResponseJSON: vendor, kind, randomized, confidence, sourceJSON: vendor, block details, virtual-machine flag (per archived homepage)
Randomized addressYes — HTTP 200, kind: randomizedCould not be tested: no API response since 2026-08-13
Vendor database downloadNo — router dataset only (CSV/JSON, CC BY 4.0)JSON, XML, CSV, Cisco vendorMacs.xml (“Order database”)
Router default loginsYes — 550 models, manufacturer-citedNo
Compliance datasetYes — free JSON feedNo
MCP serverYes — ssid-mcp on npmNo
Free lookup, no keyUnlimited per day, 60 / min burstNot quoted: no published price list reachable, none archived
Answered our logged fetches, 2026-08-13 to 2026-10-24Not logged the same way; we do not grade ourselves here0 of 44 days
Vendor data sourceIEEE MA-L, re-fetched daily at 04:00IEEE OUI/IAB (per archived homepage; refresh cadence not verifiable)
Operating since20262018 (footer: CodeLine Oy, Helsinki, © 2018–2026)

macaddress.io facts are read from the Internet Archive's capture of macaddress.io on 2026-08-07, the last capture before the outage. If macaddress.io answers when you read this, their live pages beat anything quoted here.

Where macaddress.io is the right answer

It sold the table, and ssid.ai does not. If your product needs an offline vendor database with a commercial licence behind it, in a format your stack already reads (JSON, XML, CSV, or the Cisco vendorMacs.xml layout that Cisco ISE and Meraki consume), that was macaddress.io's core offer. Its lookup also reported whether a prefix belongs to a virtual-machine vendor, which ssid.ai does not model as a field. It has operated since 2018 under CodeLine Oy in Helsinki, a longer record than ssid.ai has.

Everything in that paragraph is past tense because we cannot check any of it today. Read the next section before you build on it.

Reliability record, 2026-08-13 to 2026-10-24

We fetched every service on this site's comparison list once a day through 2026-09-11, and on Monday, Wednesday and Friday scan days since 2026-09-22. On 2026-08-13 macaddress.io answered with HTTP 523 (Cloudflare could not reach the origin). On 2026-08-19 the code changed to 521 (the origin refuses the connection) and has stayed there. On 2026-08-25 the API host stopped resolving through Cloudflare, pointing straight at an IP that refuses port 443, and status.macaddress.io stopped resolving at all.

DateHTTPcf-rayNote
2026-08-13523n/rfirst failed fetch
2026-08-14523n/r
2026-08-15523n/r
2026-08-16523n/r
2026-08-17523a2c61e210a146575-AMS
2026-08-18523a2ce5b23aa03afa0-AMS
2026-08-19521a2d698e0afed5897-AMScode changed 523 to 521
2026-08-20521a2ded5c11deb380a-FRA
2026-08-21521a2e713c0caf201e5-AMS
2026-08-22521a2ef508f0a0714bd-AMS
2026-08-23521a2f78e0d3bc726c2-AMS
2026-08-24521a2ffcb1c8b3406be-AMS/status also 521
2026-08-25521a3080e9efc8a661e-AMSapi.macaddress.io left Cloudflare; TCP 443 refused. status.macaddress.io NXDOMAIN
2026-08-26521a3104724aeff0e90-AMS
2026-08-27521a318847f5a8f5a40-AMS
2026-08-28521a320c120ef39f5c9-AMS
2026-08-29521AMS (id not kept)
2026-08-30521AMS (id not kept)
2026-08-31521n/r
2026-09-01521n/r
2026-09-02521n/r
2026-09-03521n/r
2026-09-04521a35cf67458f890a2-PRG12:22 UTC, re-fetched at ship time (11:56 UTC fetch: a35cd0150982d1c5-PRG, also 521)
2026-09-08521n/rgap 09-05 to 09-07: no logged daily fetch those 3 days, not claimed as checked
2026-09-09521n/r
2026-09-10521n/r
2026-09-11521a3942a990b1d7a96-AMSre-fetched 19:04 UTC from a SECOND network via Cloudflare's London edge: 521, cf-ray a398f0fab863ef3d-LHR
2026-09-22TIMEOUTn/rgap 09-12 to 09-21 (10 days) not logged, canonical Hetzner-Helsinki observer unreachable those days; this fetch ran from a THIRD network (not Hetzner Helsinki), api.macaddress.io and macaddress.io both timed out on TCP 443 after 10s with no TLS handshake and no cf-ray obtained. Similar to, but not confirmed identical to, the 08-25 'TCP refused' finding, since a timeout and an immediate refusal are different failure modes and this network cannot tell which one Cloudflare's edge is producing today
2026-09-23TIMEOUTn/rworld-watch scan, a FOURTH network (not Hetzner Helsinki, not the 09-22 observer): root domain (15s) and api.macaddress.io (12s) both timed out on TCP 443/HTTPS with zero bytes received, no TLS handshake, no cf-ray; status.macaddress.io still NXDOMAIN (DNS lookup failure, exit 2). DNS for the root domain still resolves through Cloudflare (two AAAA records), so the zone itself is still Cloudflare-fronted -- the failure is upstream of any HTTP response, consistent with 09-22's TIMEOUT signature, not the 08-13->09-11 521 signature. Confirms the signature change persists across a second consecutive reading; still zero third-party corroboration found this scan
2026-09-25TIMEOUTn/rworld-watch scan (Fri, gap 09-24 not a scan day): root domain and api.macaddress.io both timed out on TCP 443 (curl exit 28, max-time 15s), zero bytes, no TLS handshake. status.macaddress.io still NXDOMAIN. Third consecutive TIMEOUT reading (09-22, 09-23, 09-25), no reversion to 521 and no recovery. Zero third-party corroboration found this scan
2026-09-28TIMEOUTn/rworld-watch scan (Mon, gap 09-26/09-27 not scan days): root domain timed out on TCP 443 (curl exit 28, max-time 15s), zero bytes on the actual request -- though this network did complete a partial TLS session-ticket exchange before the request itself stalled, a slightly different signature detail than the prior 'no TLS handshake at all' reads (still no HTTP response either way). api.macaddress.io: 000/no connection. status.macaddress.io still NXDOMAIN. Root domain still resolves via Cloudflare (two A records, same edge as before). Fourth consecutive TIMEOUT-class reading (09-22, 09-23, 09-25, 09-28); 46 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-09-30522n/revolve-tick scan (Wed, gap 09-29 not a scan day): root domain returned HTTP 522 (Cloudflare connection-timed-out) on this fetch, max-time 20s -- a coded response rather than a bare TCP timeout, but still no content served. api.macaddress.io: no response within 20s (curl exit 28), same as prior reads. status.macaddress.io not re-checked this scan. Fifth consecutive TIMEOUT-class reading (09-22, 09-23, 09-25, 09-28, 09-30); 48 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-02522a44132acca878477-AMSevolve-tick scan (Fri): root domain returned HTTP 522 again, cf-ray confirms still Cloudflare-fronted. api.macaddress.io gave two disagreeing reads this tick from two different networks: a research-subagent network reported ECONNREFUSED; a direct re-check from the tick's own session ~20 min later got a plain TCP connect timeout (curl exit 28, 20s, zero bytes) against the same origin IP (95.216.69.27) -- the same TIMEOUT-class signature as every reading since 09-22, not treating the single ECONNREFUSED read as a confirmed new signature change. status.macaddress.io still NXDOMAIN. Sixth consecutive TIMEOUT/522-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02); 50 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-05TIMEOUTn/revolve-tick scan (Mon): root domain returned no HTTP response at all within 12s (curl exit 28, http_code 000) -- a bare TCP timeout, not even a coded 522 this time. api.macaddress.io: same, 000/no response, still resolves to origin IP 95.216.69.27. status.macaddress.io: DNS lookup failure (NXDOMAIN-class), confirmed via direct socket resolution, not just curl. Seventh consecutive TIMEOUT/522-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02, 10-05); 53 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-07TIMEOUTn/revolve-tick scan (Wed): root domain and api.macaddress.io both returned no HTTP response within 15s (curl exit 28, http_code 000), same bare-TCP-timeout signature as 10-05. status.macaddress.io: DNS lookup failure (NXDOMAIN-class) confirmed via direct socket resolution. Eighth consecutive TIMEOUT/522-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02, 10-05, 10-07); 55 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-09TIMEOUTn/revolve-tick scan (Fri): root domain completed its TLS handshake this time but then returned no HTTP response within 10s (curl exit 28, http_code 000) -- a slightly different partial signature than 10-05/10-07's full bare-TCP-timeout, still zero bytes served either way. api.macaddress.io: TCP connect itself never completed (curl exit 28, no TLS attempted). status.macaddress.io: DNS lookup failure (NXDOMAIN-class) confirmed via direct socket resolution. Ninth consecutive TIMEOUT/522-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02, 10-05, 10-07, 10-09); 57 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-12TIMEOUTn/revolve-tick scan (Mon): root domain returned no HTTP response within 15s (curl exit 28, http_code 000). api.macaddress.io: same, exit 28, no response. status.macaddress.io: DNS lookup failure (NXDOMAIN-class), confirmed via direct socket resolution, not just curl. Tenth consecutive timeout-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02, 10-05, 10-07, 10-09, 10-12); 60 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-14TIMEOUTn/revolve-tick scan (Wed): root domain and api.macaddress.io both returned no HTTP response within 15s (curl exit 28, http_code 000), same bare-TCP-timeout signature as the prior several reads. status.macaddress.io: DNS lookup failure (NXDOMAIN-class) confirmed via direct socket resolution. Eleventh consecutive timeout-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02, 10-05, 10-07, 10-09, 10-12, 10-14); 62 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-16TIMEOUTn/rMWF product-loop rerun (Fri, 07:18Z, from a second network -- a Dubai Mac, not the Helsinki box): root domain returned no HTTP response within 15s (curl exit 28, http_code 000, 0 bytes); api.macaddress.io: TCP connect never completed within 15s (curl exit 28). macaddress.io still resolves to a Cloudflare IP (104.21.6.242) and api.macaddress.io to origin 95.216.69.27; status.macaddress.io: DNS lookup failure (NXDOMAIN-class) via direct socket resolution. The box's own world-watch pass at ~05:10Z saw the same bare TCP timeout on both hosts. Twelfth consecutive timeout-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02, 10-05, 10-07, 10-09, 10-12, 10-14, 10-16); 64 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-19TIMEOUTn/revolve-tick scan (Mon): root domain and api.macaddress.io both returned no HTTP response within 15s (curl exit 28, http_code 000, 0 bytes). status.macaddress.io: DNS lookup failure (NXDOMAIN-class) confirmed via direct Python socket resolution. Thirteenth consecutive timeout-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02, 10-05, 10-07, 10-09, 10-12, 10-14, 10-16, 10-19); 67 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-20TIMEOUTn/revolve-tick scan (Tue): root domain and api.macaddress.io both returned no HTTP response within 15s (curl exit 28, http_code 000, 0 bytes). status.macaddress.io: DNS lookup failure (NXDOMAIN-class) confirmed via direct Python socket resolution. Fourteenth consecutive timeout-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02, 10-05, 10-07, 10-09, 10-12, 10-14, 10-16, 10-19, 10-20); 68 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-21TIMEOUTn/revolve-tick scan (Wed): root domain and api.macaddress.io both returned no HTTP response within 15s (curl exit 28, http_code 000, 0 bytes). status.macaddress.io: DNS lookup failure (NXDOMAIN-class) confirmed via direct Python socket resolution. Fifteenth consecutive timeout-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02, 10-05, 10-07, 10-09, 10-12, 10-14, 10-16, 10-19, 10-20, 10-21); 69 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-23TIMEOUTn/revolve-tick scan (Fri): root domain and api.macaddress.io both returned no HTTP response within 15s (curl exit 28, http_code 000, 0 bytes). status.macaddress.io: DNS lookup failure (NXDOMAIN-class) confirmed via direct Python socket resolution. Sixteenth consecutive timeout-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02, 10-05, 10-07, 10-09, 10-12, 10-14, 10-16, 10-19, 10-20, 10-21, 10-23); 71 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan
2026-10-24TIMEOUTn/revolve-tick scan (Sat): root domain and api.macaddress.io both returned no HTTP response within 15s (curl exit 28, http_code 000, 0 bytes). status.macaddress.io: DNS lookup failure (NXDOMAIN-class) confirmed via direct Python socket resolution. Seventeenth consecutive timeout-class reading (09-22, 09-23, 09-25, 09-28, 09-30, 10-02, 10-05, 10-07, 10-09, 10-12, 10-14, 10-16, 10-19, 10-20, 10-21, 10-23, 10-24); 72 calendar days since first failure (2026-08-13). Zero third-party corroboration found this scan

What this record is, and is not:

  • One observer. One machine in one datacentre, one plain curl per endpoint most days at about 05:00 UTC, routed through Cloudflare's Amsterdam, Frankfurt or Prague edge. The single exception is the 2026-09-11 row, re-fetched from a second network through Cloudflare's London edge, which returned the same 521. 29 days inside the span carry no logged fetch at all (2026-09-05 to 2026-09-07, 2026-09-12 to 2026-09-21, and the non-scan days since); those gaps are left visible in the table above rather than backfilled or smoothed over.
  • No third-party confirmation. On each of these days we looked for a status page, a Downdetector entry, a news item or a social post and found none. That is an absence, not a corroboration.
  • Raw headers only. From 2026-08-21 we stopped trusting any tool that summarises a response after one reported a Retry-After header the server never sent. Every row above comes from the header dump itself.
  • A record of the past. If macaddress.io loads for you, this table is history. We will add the recovery date as a row and keep the table.

Where ssid.ai is different

The lookup itself is free without a key at any daily volume (60 requests a minute burst; the router and compliance data are what the one paid plan, ssid Pro at $15/month, meters). Each response names its source:

$ curl "https://ssid.ai/api/v1/lookup?mac=00:00:0C:12:34:56"
{ "oui": "00000C", "kind": "universal", "randomized": false,
  "vendor": { "organization": "Cisco Systems, Inc", "address": "170 WEST TASMAN DRIVE SAN JOSE CA US 95134-1706" },
  "confidence": 1,
  "source": { "name": "IEEE OUI registry", "url": "https://standards-oui.ieee.org/" } }   # HTTP 200

$ curl "https://macaddress.io/"
error code: 521                                                                            # HTTP 521, 2026-09-04

Beyond the vendor table, ssid.ai holds three things macaddress.io never listed:

  • Router default logins across 550 models: gateway IP, admin username, password and reset steps, each transcribed from the manufacturer's own documentation with the source URL attached. A field with no citation does not publish.
  • The compliance index: 67% of 550 tracked models no longer ship a universal default password, the pattern the UK PSTI Act and the EU Cyber Resilience Act target, with a free JSON feed.
  • An MCP server, so an assistant calls a typed tool instead of scraping a page, plus a correction endpoint agents can write to.

Alternatives that no longer exist

WhoisXML API's MAC Address API is gone from their catalog: mac-address.whoisxmlapi.com redirects to the company homepage, the product page returns 404, and the homepage product list has no MAC entry (checked 2026-08-04 to 08-06, 2026-08-27 to 08-30, and 2026-09-04; the Internet Archive holds working captures of the API docs through 2022). We found no deprecation notice anywhere.

How to decide

Ask whether you need a file or a call. If you need the vendor database on disk under a commercial licence, macaddress.io sold exactly that, and you should check whether they still do before you look elsewhere; the IEEE's own registry at standards-oui.ieee.org is the free fallback. If you need a lookup that answers today, and you want the answer to say whether the address is randomized, what the router it hangs off logs in with, and where each fact came from, that is what ssid.ai is for.

FAQ

Is ssid.ai or macaddress.io better for MAC address lookup?
If you want the vendor table as a file you own, macaddress.io was the better fit: it sold the IEEE-derived database as JSON, XML, CSV and Cisco vendorMacs.xml, and its lookup flagged virtual-machine prefixes. ssid.ai does not sell an OUI dump. If you want a lookup API that keeps answering, ssid.ai is free without a key at any daily volume (60 requests a minute burst) and returns a typed kind field, a confidence value and the IEEE source URL on every response. The practical difference as of 2026-09-11 is that macaddress.io has returned a Cloudflare 521 or 523 on every one of our 27 logged fetches since 2026-08-13 (a 3-day gap, 09-05 to 09-07, went unfetched), so its API could not be tested on any day we checked.
Is macaddress.io down?
On our checks, yes, and it has been since 2026-08-13. One fetch from one network, through Cloudflare, daily to 2026-09-11 and on Monday/Wednesday/Friday scan days since, has failed 44 times out of 44: HTTP 523 (2026-08-13 to 08-18), then HTTP 521 with a 16-byte 'error code: 521' body (2026-08-19 to 09-21), then timeout-class from 2026-09-22 onward, meaning 15 fetches with no HTTP response at all (curl exit 28) and two HTTP 522, most recently 2026-10-24. From 2026-08-25 api.macaddress.io stopped resolving through Cloudflare and refuses TCP connections on port 443, and status.macaddress.io does not resolve. We found no status page, no Downdetector entry and no announcement, which means nobody else has confirmed this, not that it is not happening. Check https://macaddress.io/ yourself before acting on it.
What does ssid.ai return that macaddress.io does not?
Router default logins for the models in its directory (gateway IP, admin username, password and reset steps, each transcribed from the manufacturer's own documentation with the source URL attached), a compliance index with a free JSON feed, an MCP server (ssid-mcp on npm, exposing get_router_defaults, check_router_compliance, lookup_mac and submit_correction), and a dated record of which IEEE prefixes changed registrant since 2016. macaddress.io's archived homepage lists none of these; its extras are database downloads, a MAC generator and registry statistics.
Can I download the vendor database from ssid.ai like I could from macaddress.io?
No. ssid.ai publishes its router default-password dataset (CSV and JSON, CC BY 4.0, including commercial use) but does not publish an OUI vendor dump, because the IEEE already publishes that registry for free at standards-oui.ieee.org and ssid.ai ingests it daily at 04:00. macaddress.io's archived homepage offered the vendor database in JSON, XML, CSV and Cisco vendorMacs.xml under an 'Order database' button.
Does macaddress.io have an MCP server?
No. Its archived homepage lists an HTTP API with client libraries and integrations, and an npm search for macaddress.io on 2026-09-04 returns no MCP server. ssid.ai publishes ssid-mcp on npm; install it with npx -y ssid-mcp and an assistant calls lookup_mac as a typed tool with no API key.
What happened to the WhoisXML MAC Address API?
It is gone from their catalog. mac-address.whoisxmlapi.com now redirects (301) to main.whoisxmlapi.com, the product page whoisxmlapi.com/whois-api/mac-address-api ends at a 404, and the homepage product list has no MAC-address entry. The Internet Archive holds working captures of mac-address.whoisxmlapi.com/api through 2022. We checked daily on 2026-08-04 to 08-06 and 2026-08-27 to 08-30, and again on 2026-09-04, and found no deprecation notice.

Related