Apple serial number decoder: the hidden XML endpoint for legacy Mac serials

Apple's own undocumented serial number decoder lives at support-sp.apple.com and resolves the 4-character configuration code on any pre-2021 Mac serial to a marketing model name. Here's how to use it, and where its limits are.

Marcus Williams
Marcus WilliamsHardware reporter
8 min read
serial-lookupapple-supportlegacy-macsconfiguration-codemac-identification
Apple serial number decoder: the hidden XML endpoint for legacy Mac serials

Apple serial number decoder: the hidden XML endpoint for legacy Mac serials#

The most authoritative Apple serial number decoder is one Apple itself runs but does not advertise. For any 12-character Mac serial issued between 2010 and early 2021, Apple will tell you the marketing model, for free, anonymously, in a single HTTP call. The endpoint is https://support-sp.apple.com/sp/product?cc=XXXX, where XXXX is the trailing 4 characters of the serial. The response is a small XML payload with Apple's own canonical name for the device.

That endpoint is the source of truth the entire third-party Mac-lookup ecosystem was originally built on top of, and it is still the most authoritative free way to decode a legacy Mac serial. For the broader context of where the 12-character format fits across the three eras of Mac serial numbers, see the three-era serial format reference. It has two important limits, both worth understanding before you wire it into anything.

The call#

The endpoint takes one query parameter, cc, set to the 4-character configuration code:

curl 'https://support-sp.apple.com/sp/product?cc=F8J2'

The response body looks like this:

<?xml version="1.0" encoding="utf-8"?>
<root>
  <name>CPU Name</name>
  <configCode>iMac (27-inch, Late 2013)</configCode>
  <locale>en_US</locale>
</root>

Three fields. The name field carries a placeholder string ("CPU Name") on most queries. It is not the spec-rich CPU descriptor it sounds like. configCode is the field that matters: this is Apple's own marketing model name for the device, the same string you would see returned by checkcoverage.apple.com for a serial whose configuration code is XXXX. locale indicates the locale of the response.

There is no API key, no auth header, no captcha. The endpoint has been quietly serving this payload for at least a decade.

Where the configuration code lives in the serial#

The "configuration code" Apple is querying is positions 9 through 12 of a 12-character legacy serial, i.e. the last four characters. The structure of a pre-2021 serial is PPPYWSSSCCCC:

PositionsMeaning
1 to 3Manufacturing location / plant code
4Year + half-year letter
5Week within that half-year
6 to 8Random unique unit identifier (collision avoidance)
9 to 12Configuration code: model + color + storage SKU

Positions 9 through 12 are not random. They act as an index pointer into Apple's internal SKU database, encoding the model, color, storage tier, and other configuration attributes that uniquely identify the variant. Two different configuration codes can map to the same marketing model if (say) only color or storage differs, but every configuration code resolves deterministically to exactly one entry.

So when you call support-sp.apple.com/sp/product?cc=F8J2, Apple is reading the same SKU table it uses to resolve serial-numbered lookups in Check Coverage, just without requiring the rest of the serial. The endpoint is functionally a SKU dictionary, exposed as XML.

Worked example: C02XG…JG5J#

The canonical decoding example for a 12-character serial is C02XG…JG5J (a real-shape MacBook Pro serial with the unique-identifier digits redacted). The trailing four characters are JG5J.

Plugging that in:

curl 'https://support-sp.apple.com/sp/product?cc=JG5J'

Returns XML whose configCode element identifies the device as MacBook Pro (15-inch, 2018). That confirms the rest of the serial: C02 (Quanta Computer, China), X (2nd half of 2018), G (week 13 of that half, i.e. week 39 of 2018), without needing any third-party decoder.

This is the kind of confirmation that matters when you are reconciling a pile of older laptops against an asset database or unboxing a refurbished batch and want a canonical answer per unit.

Why this is more reliable than the third-party catalogs#

Several excellent third-party services aggregate Apple model data: EveryMac.com's Ultimate Mac Lookup, chipmunk.nl, Beetstech, AppleDB, The Apple Wiki. They typically return more detail than the support-sp endpoint: CPU clocks, RAM and SSD options, original price, ports, intro and discontinuation dates, A-number, EMC. For most identification work, they are the right tools. The comparison of free serial-lookup tools for Macs covers which one to reach for in which scenario.

What they all have in common is that their configuration-code tables are aggregations, assembled over years from public Apple sources, reverse engineering, and crowd contributions. Apple has never officially published the configuration-code-to-model mapping, so every third-party database carries some drift: missing codes, occasional typos, occasionally a code that maps to the wrong year.

The support-sp endpoint is the original. It is Apple's own backend reading Apple's own SKU table. There is no middleman, no aggregation, no scraping cache. For a single authoritative answer to "what model does this configuration code identify," the endpoint is the highest-confidence source available outside Apple's internal GSX portal.

That said: the endpoint is undocumented. Apple has never advertised it, has never promised it will keep running, and could shut it down or change its response shape without notice. If you depend on it in production, treat it as best-effort and have a fallback path.

What the endpoint does not return#

The support-sp endpoint is narrow on purpose. It returns the marketing model name and not much else. It does not return:

  • Specific CPU clock, RAM, or storage configuration. Two configuration codes that differ only in storage tier will both return the same configCode string in some cases.
  • Original retail price.
  • Original retailer or sale region.
  • Warranty status or AppleCare expiration. That data is keyed on the full serial, not the configuration code, and lives behind Check Coverage.
  • Repair history.
  • Current owner.

For warranty status and AppleCare, you still need checkcoverage.apple.com and the full serial number. The field-by-field Coverage Check reference covers what each returned value means and the result states a working serial can produce. For deeper spec detail (CPU clock, GPU, ports, original price), the third-party catalogs remain the right tool.

Why it doesn't work on post-2021 serials#

In March 2021, Apple began transitioning to randomized 8-to-14-character serials, with 10 characters as the typical implementation. The leaked internal memo confirming the transition was explicit that the new format "will no longer include manufacturing information or a configuration code" (MacRumors, 9 Mar 2021; corroborated by AppleInsider and 9to5Mac). The motivations behind that change are covered in the full timeline of Apple's 2021 serial randomization.

Without a configuration code embedded in the serial, there is nothing to pass as the cc parameter. Apple's internal database still links every randomized serial to the SKU it was assigned at the factory (that is why Check Coverage can return the marketing model for a 2023 MacBook Pro), but the link is a database lookup keyed by the full serial, not a deterministic decoding of any subset of characters.

In practical terms: support-sp works through the 2021 model year for SKUs that were still shipping with structured 12-character serials, and fails for any device that shipped with a randomized 10-character serial. The 24-inch iMac M1 launched in mid-2021 with the old format, so its configuration codes are queryable. The 14- and 16-inch MacBook Pro with M1 Pro / M1 Max, released in October 2021, were among the first Macs to ship with randomized serials, so their owners cannot use this endpoint at all.

All M2, M3, and M4 generation Macs are exclusively randomized-serial, so the endpoint is functionally a legacy tool. It will keep being useful as long as there is older hardware in circulation. Given that Macs routinely run a decade in the field, that will be a long time.

When this matters#

The audience for this endpoint is narrow but specific.

If you are a sysadmin reconciling an inventory of older Macs against an asset management database, the support-sp endpoint is scriptable. A shell loop over a CSV of serials, extracting positions 9 through 12 and curl-ing the endpoint, gives you canonical model names in seconds without rate-limit concerns the third-party services impose on free tiers. If you'd rather skip the shell loop entirely, the spot-check any Mac serial before paying tool does the same lookup interactively.

If you are a repair shop or refurbisher receiving mixed batches of Intel-era Macs, the endpoint resolves identification disputes. When a unit's etched serial conflicts with what System Information reports (a known artifact of logic-board replacements), the configuration code is the deciding evidence.

If you are a buyer of older hardware and want to verify a seller's claimed model against the actual configuration code embedded in the serial, without trusting any third-party site, the support-sp call is the cleanest single check available. Combined with checkcoverage.apple.com for the warranty and registration date, you have two of the three identification pieces Apple itself attests to. The third, repair history, only lives in GSX, and the reasons no public site can read it are in the GSX walkthrough for buyers and sellers.

For post-2021 hardware, none of this applies. The serial is a dumb token and only Apple's servers can resolve it. But for the substantial installed base of pre-2021 Macs still in use, sale, and repair pipelines, Apple's own undocumented endpoint remains the highest-confidence free way to confirm what a given configuration code actually identifies.

Check a serial

Have a serial in front of you? The Macfax lookup reads the model, year and configuration, and shows what Apple's own tools leave out.

Marcus Williams

Written by

Marcus Williams

Hardware reporter

Marcus Williams covers Mac hardware and repair for Macfax. He spent six years on the bench at an Apple Authorized Service Provider in the Pacific Northwest before going independent, most of that time on logic-board repair, display assembly swaps, and the failure patterns Apple's diagnostics don't surface. He writes about what's inside a Mac, what breaks first, and what a serial number can and can't tell you about a unit's history.

More posts by Marcus