Our MAC Address Vendor/Manufacturer Lookup API allows you to query against our database and obtain information about any MAC address or OUI. Our simple to use RESTful API makes it easy to implement into any application you are building.
We pay for this site from our own pockets, ads, and donations. If you feel compelled (and you SHOULD!) to help us out, you can donate here :)
If you are querying too fast, in an inefficient or in an irresponsible way, we will initially throttle API requests coming from the specific IP address. If it continues, we will temporarily ban your IP block and any associated IP blocks registered through ARIN. If you are having any issues or no longer receiving a response from our API, please Contact Us so we can work out a custom solution to fit your needs.
To use our API, just send a GET or POST request to https://api.macaddresslookup.app/MAC_ADDRESS and you will receive a JSON encoded output.
Queries must be at least 6 hexadecimal characters long to be able to determine the manufacturer. However, some OUIs issued by IEEE are split into smaller chunks for companies that do not require a full OUI24 block. In that case, the first 6 characters of the MAC address will not be enough and you will need to supply 8 characters to query our OUI36 database. If at all possible, send the full MAC address in any format for the best possible result.
By default, our API provides a JSON encoded response.
[
{
"startHex":"0023AB000000",
"endHex":"0023ABFFFFFF",
"startDec":"153192759296",
"endDec":"153209536511",
"company":"CISCO SYSTEMS, INC.",
"addressL1":"170 W. TASMAN DRIVE",
"addressL2":"M\/S SJA-2",
"addressL3":"SAN JOSE CA 95134-1706",
"country":"UNITED STATES",
"type":"MA-L"
}
]
The two relavent response headers provided are HTTP/1.1 200 OK and Content-Type: application/json
In all of the reponse formats, the order of the values are the same. A description of each value is below.
If there is no match in our database, you will receive an empty response with a status code of HTTP/1.1 204 No Content
If you would like to specify a different output, append a /{OutputFormat} to the end of your query. Valid output formats are json, xml, csv, and pipe. The output from each type are below.
https://api.macaddresslookup.app/0023AB7B5899
[
{
"startHex": "0023AB000000",
"endHex": "0023ABFFFFFF",
"startDec": "153192759296",
"endDec": "153209536511",
"company": "Cisco Systems, Inc",
"addressL1": "80 West Tasman Drive",
"addressL2": "San Jose CA 94568",
"addressL3": "",
"country": "US",
"type": "MA-L"
}
]curl -s https://api.macaddresslookup.app/0023AB7B5899 | jq[
{
"startHex": "0023AB000000",
"endHex": "0023ABFFFFFF",
"startDec": "153192759296",
"endDec": "153209536511",
"company": "Cisco Systems, Inc",
"addressL1": "80 West Tasman Drive",
"addressL2": "San Jose CA 94568",
"addressL3": "",
"country": "US",
"type": "MA-L"
}
]
https://api.macaddresslookup.app/0023AB7B5899/xml
<?xml version="1.0" encoding="utf-8"?> <result> <startHex>0023AB000000</startHex> <endHex>0023ABFFFFFF</endHex> <startDec>153192759296</startDec> <endDec>153209536511</endDec> <company>CISCO SYSTEMS, INC.</company> <addressL1>170 W. TASMAN DRIVE</addressL1> <addressL2>M/S SJA-2</addressL2> <addressL3>SAN JOSE CA 95134-1706</addressL3> <country>UNITED STATES</country> <type>MA-L</type> </result>
The two relavent response headers provided are HTTP/1.1 200 OK and Content-Type: application/xml
https://api.macaddresslookup.app/00:23:AB:7B:58:99/csv
"0023AB000000","0023ABFFFFFF","153192759296","153209536511","CISCO SYSTEMS, INC.","170 W. TASMAN DRIVE","M/S SJA-2","SAN JOSE CA 95134-1706","UNITED STATES","MA-L"
The two relavent response headers provided are HTTP/1.1 200 OK and Content-Type: text/csv
https://api.macaddresslookup.app/0023.ab7b.5899/pipe
0023AB000000|0023ABFFFFFF|153192759296|153209536511|CISCO SYSTEMS, INC.|170 W. TASMAN DRIVE|M/S SJA-2|SAN JOSE CA 95134-1706|UNITED STATES|MA-L
The two relavent response headers provided are HTTP/1.1 200 OK and Content-Type: text/plain
We designed our API in a very RESTful way, so that your consumption of it is simple and straightforward. From Wikipedia:
REST's proponents argue that the Web's scalability and growth are a direct result of a few key design principles:
All resources share a uniform interface for the transfer of state between client and resource, consisting of
A protocol which is:
REST's client/server separation of concerns simplifies component implementation, reduces the complexity of connector semantics, improves the effectiveness of performance tuning, and increases the scalability of pure server components. Layered system constraints allow intermediaries-proxies, gateways, and firewalls-to be introduced at various points in the communication without changing the interfaces between components, thus allowing them to assist in communication translation or improve performance via large-scale, shared caching.