Unsolved "The account does not have access to that quota" - API v1 URL Metrics
-
Hi!
On one of our servers we get the message "The account does not have access to that quota" when pulling data for v1 URL Metrics endpoint in the API.
This only happens on one specific server, others have worked flawlessly. Any idea of what might be going on?Thanks
-
Same here.
-
@aheitzman same thing for me. This problem is recent.
Got a burning SEO question?
Subscribe to Moz Pro to gain full access to Q&A, answer questions, and ask your own.
Browse Questions
Explore more categories
-
Moz Tools
Chat with the community about the Moz tools.
-
SEO Tactics
Discuss the SEO process with fellow marketers
-
Community
Discuss industry events, jobs, and news!
-
Digital Marketing
Chat about tactics outside of SEO
-
Research & Trends
Dive into research and trends in the search industry.
-
Support
Connect on product support and feature requests.
Related Questions
-
Unsolved MOZ API to Google Data Studio
Dopes MOZ have anything like this? https://www.semrush.com/features/google-data-studio-connector/
Product Support | | WebMarkets0 -
Unsolved Can I get Moz keywords via API?
Hi, my boss is asking if you "have any API for keyword research -- e.g., as soon as a user creates a card title in [our application], we can auto-recommend keywords from Moz within [the application]. I shared a link with him to your Links API page, but he says he doesn't think that API does the above. Can you help? Thank you, Renae
API | | CarolinaRen0 -
Unsolved url_metrics - Error deserializing POST body
Hi, I'm trying to reproduce this Postman url_metrics request in Google Apps Script (GAS) : moz forum 2-2.jpg But in GAS, I get this error : moz-forum 2.jpg I suspect it's the body (line 90) that causes the issue, but can't figure out how to fix it. Any suggestion ?
API | | adalako0 -
What does "ffspl" mean in a url-metrics result set?
So I've got this server-side JScript object I've declared which works nicely for us. var mozObj = new MozInteraction()
API | | StevePoul
.setMethod("GET")
.setHost("http://lsapi.seomoz.com")
.setPath("linkscape/url-metrics")
.setCols(parseInt("11111111111111111111111111111111111111111111111111111", 2))
.setLines(10)
.setAccessId(accessId)
.setSecret(secret)
.setExpires((new Date()).addDays(1).valueOf())
.generateSignature(); etc etc The setCols call sets the Cols value to the maximum possible: 9007199254740991. The weird thing is that in the JSON response I get a whole pile of column names that I can't find descriptions for in the documentation at https://moz.com/help/links-api/making-calls/response-fields e.g. ffspl1 ffspl2 ffspl3 ... fuspl0 fuspl1 fuspl2 fuspl3 ... pfspl0 pfspl1 pfspl2 pfspl3 ... puspl0 puspl1 puspl2 puspl3... etc1 -
Paid access to the API
Hi!
API | | SlemmaDev
We paid for the trial period, but we don't have access to the API (Anchor-Text Metrics, and to the other paid URL Metrics). Why? Thanks!0 -
How to retrieve keyword difficulty information using Mozscape API?
Hi, Are we possible to use Mozscape API to retrieve keyword difficulty information for a list of keywords? I can't find its documentation. Thanks
API | | uceo0 -
Suggestion - How to improve OSE metrics for DA & PA
I am sure everyone is aware at Moz, that although the Moz link metrics ( primarily I am talking about DA & PA) are good, there is a lot of room for improvement, and that there are a lot of areas where the metric values given to some types of site are well out of whack with what their "real" values should be. Some examples
API | | James77
www.somuch.com (Link Directory) - DA 72
www.articlesbase.com (Article Directory) - DA 89
www.ezinearticles.com (Article Directory) - DA 91 I'm sure everyone would agree that links from these domains are not as powerful (if of any value at all), as their DA would suggest, and therefore by definition of how moz metrics work, the sites these have links from such sites are also inflated - thus they throw the whole link graph out of whack. I have 2 suggestions which could be used to singularly or in conjunction (and obviously with other factors that Moz use to calculate DA and PA) which could help move these values to what they should more realistically be. 1/. Incorporate rank values.
This is effectively using rank values to reverse engine what google (or other engines) as a "value" on a website. This could be achieved (if moz were not to build the data gathering system itself), by intergrating with a company that already provides this data - eg searchmetrics, semrush etc. As an example you would take a domian and pull in some rank values eg http://www.semrush.com/info/somuch.com?db=us - where you could use traffic, traffic price, traffic history as a metric as part of the overall Moz scoring alogrithm. As you can see from my example according to SEMRush the amount of traffic and traffic price is extreamly low for what you would expect of a website that has a DA of 72. Likewise you will find this for the other two sites and similarly to pretty much any other site you will test. This is essentially because your tapping into Googles own ranking factors, and thereby more inline with what real values (according to Google) are with respect to the quality of a website. Therefore if you were to incorporate these values, I believe you could improve the Moz metrics. 2/. Social Sharing Value
Another strong indicator of quality the amount of social sharing of a document or website as a whole, and again you will find as with my examples, that pages on these sites have low social metrics in comparison to what you would normally associate with sites of these DA values. Obviously to do this you would need to pull social metrics of all the pages in your link DB. Or if this we to tech intense to achieve, again work with a partner such as searchmetrics, which provide "Total Social Interations" on a domain level basis. Divide this value by the number of Moz crawled pages and you would have a crude value of the overall average social scorability of a webpage on a given site. Obviously both the above, do have their flaws if you looked at them in complete isolation, however in combination they could provide a robust metric to use in any alogrithm, and in combination with current moz values used in the alogrithm I believe you could make big strides into improving overall Moz metrics.1