Moz API V1 Archive: Guide to API Response Fields – Help Hub – Moz

Note: This guide focuses on the archived Moz API V1 response-field logic that powered classic Mozscape-style requests and JSON outputs.

Some old APIs age like milk. Moz API V1 is not one of them. Sure, it is archived, a little creaky, and carries the unmistakable aroma of an earlier SEO era, but it still teaches one of the best lessons in API design for marketers and developers: ask only for what you need, then learn exactly what every returned field means.

That is the real heart of the old “Guide to API Response Fields” concept. Moz API V1 did not just hand back a giant mystery blob and wish you luck. It used a compact system of bit flags and short response keys so you could request a tight payload and interpret it field by field. Once you understand that logic, the strange little abbreviations like upa, pda, ueid, and ulc stop looking like keyboard accidents and start looking like a practical SEO toolkit.

This guide breaks down how those response fields worked, why they mattered, and how to read them without staring at your JSON like it owes you money.

Why the Moz API V1 Archive Still Matters

The archived Moz API V1 documentation is still useful because it captures an older but very influential way of exposing SEO data. Many tools, dashboards, browser extensions, spreadsheets, and custom scripts were built around these response fields. If you ever worked with Mozscape integrations, historical SEO reports, custom backlink dashboards, or dusty-but-beloved internal automation, chances are these field names are still hiding in your codebase.

More importantly, the archive explains the difference between requesting a metric and reading a response field. That distinction matters. In Moz API V1, you did not simply say, “Give me everything.” You selected metrics through a numeric Cols value. Moz then returned specific field names in JSON. One request could yield one field, or sometimes multiple fields. In other words, what you asked for and what you got back were related, but not always identical twins.

That design still feels modern. It keeps responses lean, avoids unnecessary data, and forces you to be intentional. No fluff. No field buffet. No accidental ten-pound payload for a one-pound question.

How Moz API V1 Built a Response

At a high level, the old workflow looked like this:

1. Create an authenticated request using an Access ID, an expiration timestamp, and a signed HMAC-SHA1 signature.
2. Send the request to a Mozscape endpoint such as url-metrics.
3. Pass a numeric Cols parameter that represented the metrics you wanted.
4. Receive a JSON response with short field names tied to those requested metrics.

The authentication step looked technical, but the logic was simple: build a string using your Access ID and expiration time, sign it, encode it, and attach it to the request. If you were querying a single URL, the URL often appeared in the path. If you were batching multiple URLs, the request body could hold a JSON array of URLs.

The charmingly nerdy part was Cols. Every metric had a bit flag value. To request multiple metrics, you added those values together. Yes, really. It was part math puzzle, part API request, and part rite of passage for technical SEOs.

The Two Things That Confuse Everyone First

1) Bit flags are request selectors, not response field names

Suppose you wanted the canonical URL, Page Authority, and Domain Authority. In the old URL Metrics setup, those values mapped to these bit flags:

• 4 = canonical URL
• 34359738368 = Page Authority
• 68719476736 = Domain Authority

Add them together and you get 103079215108. That total became your Cols parameter. Moz then returned JSON fields such as uu, upa, and pda.

So the request language was numeric, while the response language was abbreviated text. Once you understand that split, the whole system becomes far less spooky.

2) One requested metric can return multiple fields

This is where newcomers often blink twice. Some Moz metrics returned more than one response field. For example, requesting MozRank for a URL produced both a normalized score and a raw score:

• umrp = normalized MozRank
• umrr = raw MozRank

Likewise, the Spam Score bundle returned multiple fields related to spam, language, crawl status, crawl time, and related pages. So if your response suddenly looked more crowded than expected, that was not always a bug. Sometimes the API was just being thorough.

The Most Important Moz API V1 Response Fields

Let’s translate the greatest hits.

Identity and page basics

• ut The page title, if available.
• uu The canonical form of the URL.
• ufq The subdomain.
• upl The root domain.
• us The HTTP status code recorded for that URL.
• ulc The time the URL was last crawled, usually in Unix epoch format.

These fields help you answer the first sanity-check question in SEO data work: “Are we even talking about the page we think we are?” If a URL canonicalizes somewhere unexpected, returns a status code you did not expect, or shows an old crawl time, your shiny authority metrics may need a little side-eye.

Link counts and linking domains

• ueid External equity links to the URL.
• uid Total links to the URL.
• uifq Subdomains with pages linking to the URL.
• uipl Root domains with pages linking to the URL.
• fid Subdomains linking to the subdomain.
• pid Root domains linking to the root domain.

This is one of the most useful distinctions in the archive. Not all links are created equal, and Moz’s field names reflect that. ueid refers to external equity links, which are more selective than broad total link counts. Meanwhile, uid is more inclusive. If your data looked weird because one count was much lower than another, that was often not an error. It was the difference between total links and a narrower quality-oriented slice.

Authority fields everyone remembers

• upa Page Authority.
• pda Domain Authority.

These were the celebrity fields. They often got requested explicitly and then pasted into dashboards, pitch decks, and spreadsheets with dramatic flair. Used properly, they were comparative signals. Used badly, they turned into a personality test for websites.

The smart way to read them is as predictive third-party metrics, not divine truth. Page Authority is page-level. Domain Authority is domain-level. Both are helpful for comparison, prioritization, and rough competitive analysis. Neither should be treated like Google’s own ranking formula wearing a fake mustache.

MozRank, MozTrust, and related pairs

• umrp / umrr URL MozRank, normalized and raw.
• fmrp / fmrr Subdomain MozRank, normalized and raw.
• pmrp / pmrr Root domain MozRank, normalized and raw.
• utrp / utrr URL MozTrust, normalized and raw.
• ftrp / ftrr Subdomain MozTrust, normalized and raw.
• ptrp / ptrr Root domain MozTrust, normalized and raw.

If the paired fields look repetitive, that is because they are intentionally paired. The normalized versions are easier for humans to read. The raw versions are there for people who enjoy granularity, spreadsheets, and possibly controlled chaos.

Spam Score and contact-related bundles

• fspsc Spam score for the page’s subdomain.
• fspf Triggered spam flags.
• flan Language of the subdomain.
• fsps HTTP status code of the spam crawl.
• fsplc Last spam crawl time.
• fspp Pages used for the spam crawl.

There was also a social/contact bundle with fields such as Facebook account, Twitter handle, and email address. That bundle came with an important warning in the documentation: automatically collected email addresses were not suitable for CAN-SPAM style outreach use. In plain English: just because a field exists does not mean it came with permission to act like a digital raccoon in someone’s inbox.

An Illustrative Response Example

Here is a simplified example of the sort of JSON you might see after requesting a handful of popular URL Metrics fields. These values are illustrative, not tied to a real live request:

Notice how compact that is. The abbreviations save space, but the trade-off is readability. That is why archived field guides were so important. Without a reference table, the output looked like a bowl of alphabet soup served by an overcaffeinated engineer.

How to Read the Response Like a Pro

Start with uu and us. Confirm the canonical URL and status code before trusting anything else. If the page is not canonical where you think it is, or if Moz recorded a non-200 response, the rest of the data may not support the conclusion you planned to put in your report.

Next, compare uid and ueid. This tells you whether the page simply has links or has a healthier slice of external equity links. Then look at upa and pda together. A page can live on a strong domain without being a strong page. Likewise, a solid page can exist on a weaker domain and still punch above its weight.

After that, check the MozRank or MozTrust pairs if you need more nuance. And finally, use ulc to understand data freshness. Crawl timing matters. Stale crawl data can make a clean-looking report tell a stale story.

Common Mistakes With Moz API V1 Response Fields

Mistake #1: Treating abbreviations as random

The fields were short, but not meaningless. Once mapped, they were consistent and efficient. Create your own legend once, and your future self will send a thank-you card.

Mistake #2: Confusing authority with ranking truth

Domain Authority and Page Authority are useful benchmarks, but they are not Google ranking factors. They are Moz metrics designed to estimate comparative ranking potential. That makes them valuable, but not magical.

Mistake #3: Forgetting that one metric can expand into multiple fields

Requesting MozRank or Spam Score and then being surprised by multiple returned fields is a classic move. The API was doing exactly what it said it would do. It was just doing it in shorthand.

Mistake #4: Ignoring HTTP status and crawl timing

If you skip us and ulc, you risk analyzing a URL that Moz saw differently than you do now. That is a quick route to bad decisions and awkward explanations.

What the Archive Still Teaches Modern SEO Teams

The biggest lesson from this archived guide is discipline. Modern APIs often make field selection easier and more human-readable, but the underlying principle is the same: request only what you need, know what each field means, and separate raw data from interpretation.

Moz API V1 was excellent at forcing that clarity. If you wanted a compact SEO dashboard, you needed to understand your bit flags. If you wanted readable reporting, you needed to translate response keys into plain English. If you wanted trustworthy analysis, you needed to know the difference between total links, equity links, page-level metrics, domain-level metrics, crawl data, and spam-related signals.

In other words, the archive is not just a fossil. It is a class in technical SEO thinking.

Experience Notes: What Working With Moz API V1 Response Fields Actually Felt Like

For a lot of SEOs, analysts, and developers, working with Moz API V1 felt like joining a club where the password was “Why is this field called uipl?” The first experience was usually confusion. You would send a request, get a tight little JSON response back, and immediately realize that compactness is wonderful right up until you have to explain it to another human being.

Then came the spreadsheet era. People pulled Moz fields into Excel, Google Sheets, browser extensions, custom scripts, and reporting dashboards. One team member would memorize that upa meant Page Authority. Another would remember that pda meant Domain Authority. Nobody remembered everything, so somewhere in the company there was always a tab named something like DO NOT DELETE – MOZ FIELD MAP. That tab was the closest thing the office had to sacred text.

There was also a weird satisfaction in building the Cols parameter. Yes, it was awkward. Yes, it looked like you dropped your keyboard onto a calculator. But once you understood the bit flags, it became oddly empowering. You were not just calling an API; you were assembling a custom answer. Want canonical URL, status, links, Page Authority, and last crawl time? Fine. Add the values, send the request, and enjoy your carefully curated pile of abbreviations.

The practical experience also taught humility. It was easy to obsess over DA and PA because they were visible, easy to chart, and impressively numeric. But anyone who worked with the response fields for long enough learned that context mattered more. A page with decent upa and poor status data was a problem. A domain with strong pda and weak page-level signals was not automatically a win. A big link count without strong equity signals could be a flashy number with very little muscle behind it.

Another memorable part of the experience was debugging. When something looked off, the field map helped. If a result seemed suspicious, you could check the canonical URL, the HTTP status, the crawl time, the type of links returned, and whether you had requested the right metrics in the first place. Moz API V1 did not remove complexity, but it made complexity inspectable. That is a huge reason technical users respected it.

And finally, there was the translation problem. Moz API V1 was built for machines first and humans second, so experienced users got good at turning API shorthand into executive-friendly language. They learned to say “root domains linking” instead of uipl, “last crawled” instead of ulc, and “external equity links” instead of making everyone pretend they naturally speak fluent acronym. In that sense, the experience of using the archive was not just technical. It was editorial. You had to understand the data deeply enough to explain it clearly, and that is still one of the most valuable SEO skills around.

Conclusion

The Moz API V1 archive remains one of the clearest examples of how SEO data can be both compact and powerful. Its response fields may look cryptic at first glance, but they are highly structured once you understand the rules. The Cols parameter tells Moz what to return, and the response fields tell you exactly what came back. From ut and uu to upa, pda, ueid, and ulc, each field has a specific role in interpreting page identity, link signals, authority, and crawl context.

If you are revisiting legacy code, maintaining an old integration, or simply trying to understand how classic SEO APIs shaped today’s tooling, this archived guide is still worth your time. It teaches precision, data literacy, and one timeless lesson: short field names are only scary until you know what they mean.

SEO Tags