Server >> web api rate limits

Technical Issue Reporting
#39

yes to the first question, for the second question, there are few cases where that value is different, for example in the case of resync metadata endpoint, where you can call it only once per second as it has a rateLimitWeight of 60

information about high offset is not present there, we are working on improving the backend infrastructure now and we don’t have cursor implementation for every endpoint now

#40

OK. So actually, none of the questions were answered yet. Let me recap them, and the non-answers we got so far:

  1. What do the rate limit error headers mean? These docs only define a few of them. We need a full and precise reference.
  2. What are the “throttle limit” request weights? These docs show weights for “speedy nodes” and for “api” but not for the “throttle limit.” --> You referred to rateLimitWeight in the endpoint /info/endpointWeights but then also said it’s missing some of the current weights. Is there a complete list we can trust somewhere?
  3. If a throttle limit is hit, how long is service blocked? Until the next second? minute? day? --> You said “it should be until the next second” - is it actually until the next second?
  4. If it is really possible to reach 3,500 requests per minute without hitting a “throttle limit” please show code that does so.
#41

Bottom line is: Moralis API and features are among the best in this space, but Rate Limits are obscure and overcomplicated. Lets be blunt ----- > rethink, redo.

2 Likes
#42

Hi all

we will update our rate limit pricing and information

its too confusing

thanks for feedback

1 Like
#43

We changed now so everything is per second

You only have to care about 1 variable which is rate limit per second

Hope it helps!!

2 Likes
Rate limit change
#44

Thanks @ivan. This is a great step in the right direction!
But, are we still subject to the “request weight” system for the per-second limit? If so, can we get a complete list of “request weights” that count toward this limit? @cryptokid mentioned an endpoint above, but then said it’s missing some weights. Like for high-offset.

#45

now that high offset limit will be capped at 25 so you can make one request in a second

1 Like
#46

@cryptokid I assume you mean

  1. Yes, we are still subject to the “request weight” system
  2. The weights are in the endpoint /info/endpointWeights
  3. That endpoint now shows all request weights, including the weights of “high offset” requests and any other corner cases you guys charge extra for
  4. High offset requests now cost 25 units

Is this what you mean?

#47

I’ll have to check how it is with high offset, in that case the rate was variable based in the offset value.

#48

Right. We need a reference with all the request weights. Not just some.

#49

there is this page:
https://docs.moralis.io/misc/rate-limit

that also contains a link to a forum post that says how the weight for high offset is computed

(If you are using NFT endpoints with offset - please read this as they have temporarily different special weights).
#50

First, that page says “these are temporary restrictions we had to put in place as we scale our systems and will be removed in the coming week approximately” and the post was dated Dec 2021, 3+ months ago. Did you remove these restrictions? If not, when will they be removed?

Second, is this formula limited to NFT endpoints? I think you have something similar for all endpoints with high-offsets. Like transactions, erc transfers, etc.

Third, this should all be part of a single list of request weights. Making us gather pieces of data from different blog posts is not a great experience.

#51

Following up on these. We are still getting rate-limited with getTokenTransfers with a high-offset. Not an NFT endpoint.

Can we avoid the high-offset penalty by using to_block instead of offset?

#52

can you give more details?

like an example of offset and address where you get that rate limit?
and also the error message for that rate-limit?

#53

I provided the endpoint and error msg above. To others reading, the answer is yes, using to_block worked.

@cryptokid please respond to these.

First, that page says “these are temporary restrictions we had to put in place as we scale our systems and will be removed in the coming week approximately” and the post was dated Dec 2021, 3+ months ago. Did you remove these restrictions? If not, when will they be removed?

Second, is this formula limited to NFT endpoints? I think you have something similar for all endpoints with high-offsets. Like transactions, erc transfers, etc.

Third, this should all be part of a single list of request weights. Making us gather pieces of data from different blog posts is not a great experience.

#54

the restrictions are not removed yet

if you look on the http headers for every request, you could see if there is an impact from offset or not, in particular for some endpoint, if they have a lot of data (for example if you try with a Binance hot wallet address like 0x8894E0a0c962CB723c1976a4421c95949bE2D4E3) , you could get a timeout error

I don’t know now of high offset impact for non NFT endpoints.

#55

Can you find out please? And also when the “temp restrictions” from 3 months ago will be lifted?

#56

I found out now that all endpoints that use offset as a parameter have the increasing weight.

We don’t have an ETA now for when the restrictions will be lifted.

#57

This is a bit like saying “all endpoints that penalize offsets penalize offsets.”
Can we at least have a list of them? It’s not just the one mentioned in the blog post you linked to. What’s the penalty formula for each?

#58

we have this request for example:

https://deep-index.moralis.io/api/v2/0x965F527D9159dCe6288a2219DB51fc6Eef120dD1?chain=bsc&offset=5000

in headers it returns:

x-rate-limit-limit: 25
x-rate-limit-used: 10
x-request-weight: 1
x-rate-limit-remaining-ip-ttl: 1
x-rate-limit-remaining-ttl: 1
x-rate-limit-ip-used: 10

that means that one request without offset has a weight of 1 (x-request-weight: 1), and because I used offset 5000 in this case, it was counted for rate limit as a weight of 10 (x-rate-limit-ip-used: 10).

that 10 is computed as 5000/500 * 1

for another endpoint:

https://deep-index.moralis.io/api/v2/0x965F527D9159dCe6288a2219DB51fc6Eef120dD1/erc20/transfers?chain=bsc&offset=5000

we have:

x-rate-limit-limit: 25
x-rate-limit-used: 20
x-request-weight: 2
x-rate-limit-remaining-ip-ttl: 1
x-rate-limit-remaining-ttl: 1
x-rate-limit-ip-used: 20

here the formula is 5000/500 * 2

meaning that the formula is offset / 500 * request-weight