Missing weight headers in SAPI endpoints

API Spot/Margin API
,
1

Hello,

I have already contacted the customer support about this issue but I would like to start a discussion here as well.

I have noticed that most SAPI endpoints do not return a weight header x-mbx-used-weight-1m and the few that do return x-mbx-used-weight-60s which is hugely inconsistent.

For example, if I call the endpoint sapi/v1/accountSnapshot I get back the following headers :

{
‘content-type’: ‘application/json;charset=UTF-8’,
‘content-length’: ‘38’,
connection: ‘close’,
date: ‘Mon, 20 Apr 2020 06:10:46 GMT’,
server: ‘nginx’,
‘x-application-context’: ‘sapi:bnb-prod:9056’,
‘strict-transport-security’: ‘max-age=31536000; includeSubdomains’,
‘x-frame-options’: ‘SAMEORIGIN’,
‘x-xss-protection’: ‘1; mode=block’,
‘x-content-type-options’: ‘nosniff’,
‘content-security-policy’: ‘default-src ‘self’’,
‘x-content-security-policy’: ‘default-src ‘self’’,
‘x-webkit-csp’: ‘default-src ‘self’’,
‘cache-control’: ‘no-cache, no-store, must-revalidate’,
pragma: ‘no-cache’,
expires: ‘0’,
‘access-control-allow-origin’: ‘*’,
‘access-control-allow-methods’: ‘GET’,
‘x-cache’: ‘Miss from cloudfront’,
via:
‘1.1 28bd9e684280f6bbd2062058d3755625.cloudfront.net (CloudFront)’,
‘x-amz-cf-pop’: ‘YTO50-C1’,
‘x-amz-cf-id’: ‘DtECZd5wmPX5O-QwLkOY3NSlSL__cyr1ZLys7izcgzDmLuCC3itkhA==’
}

Notice the lack of any weight headers.

If I call an API endpoint like /api/v3/ping I will get the standard x-mbx-used-weight-1m like so :

{
‘content-type’: ‘application/json;charset=utf-8’,
‘transfer-encoding’: ‘chunked’,
connection: ‘close’,
date: ‘Mon, 20 Apr 2020 16:24:37 GMT’,
server: ‘nginx’,
vary: ‘Accept-Encoding’,
‘x-mbx-uuid’: ‘47d4f0e6-0ae2-4225-929b-26694e3d431d’,
‘x-mbx-used-weight’: ‘3’,
‘x-mbx-used-weight-1m’: ‘3’,
‘strict-transport-security’: ‘max-age=31536000; includeSubdomains’,
‘x-frame-options’: ‘SAMEORIGIN’,
‘x-xss-protection’: ‘1; mode=block’,
‘x-content-type-options’: ‘nosniff’,
‘content-security-policy’: ‘default-src ‘self’’,
‘x-content-security-policy’: ‘default-src ‘self’’,
‘x-webkit-csp’: ‘default-src ‘self’’,
‘cache-control’: ‘no-cache, no-store, must-revalidate’,
pragma: ‘no-cache’,
expires: ‘0’,
‘access-control-allow-origin’: ‘*’,
‘access-control-allow-methods’: ‘GET’,
‘content-encoding’: ‘gzip’,
‘x-cache’: ‘Miss from cloudfront’,
via:
‘1.1 bd1b8afd711c9f603d05a3466e054c6a.cloudfront.net (CloudFront)’,
‘x-amz-cf-pop’: ‘YTO50-C2’,
‘x-amz-cf-id’: ‘8hLWM_fr8nwNZl7fjgPnxmDp0DzGThgnDjQUFn2-hYGlQpWieRUlgQ==’
}

I did some further testing as I thought maybe this was merely a display bug and the weights on the server were accurate but this seems to not be the case.

For example, if I call a SAPI endpoint that is known to return the x-mbx-used-weight-60s header (sapi/v1/accountSnapshot with a weight of 1) after calling one that doesn’t (sapi/v1/margin/asset with a weight of 5) I do not get the expected weight in the header (6).

Instead I get only the weight of the request that returns the header as shown below :

{
‘content-type’: ‘application/json;charset=UTF-8’,
‘content-length’: ‘149’,
connection: ‘close’,
date: ‘Mon, 20 Apr 2020 16:33:24 GMT’,
server: ‘nginx’,
‘x-application-context’: ‘sapi:bnb-prod:9056’,
‘x-mbx-used-weight-60s’: ‘1’,
‘strict-transport-security’: ‘max-age=31536000; includeSubdomains’,
‘x-frame-options’: ‘SAMEORIGIN’,
‘x-xss-protection’: ‘1; mode=block’,
‘x-content-type-options’: ‘nosniff’,
‘content-security-policy’: ‘default-src ‘self’’,
‘x-content-security-policy’: ‘default-src ‘self’’,
‘x-webkit-csp’: ‘default-src ‘self’’,
‘cache-control’: ‘no-cache, no-store, must-revalidate’,
pragma: ‘no-cache’,
expires: ‘0’,
‘access-control-allow-origin’: ‘*’,
‘access-control-allow-methods’: ‘GET’,
‘x-cache’: ‘Miss from cloudfront’,
via:
‘1.1 8f6d71bb81b560f2d0dc99b1cbb17aa8.cloudfront.net (CloudFront)’,
‘x-amz-cf-pop’: ‘YTO50-C2’,
‘x-amz-cf-id’: ‘eUufAtY59vGciYUiDpx5aEjpNYxYXhwq96fPlNFnD62djkesl3x_nw==’
}

Now my question/request is two-fold:

  1. Can we fix all the SAPI endpoints that do not return any weight headers?
  2. Can we make the SAPI header names consistent with the API and FAPI header names? (x-mbx-used-weight-1m)

Thanks,

2

Could I get some feedback about the issue above from the dev team?

I’d like to know if I have to program a fix on my side or if this is gonna be fixed server-side eventually.

Thanks!

3

Thank you for the feedback, we have forwarded this issue to the dev team and still waiting for the reply.

4

Hi Dino,

Thanks for the reply, do you have any news on the issue above? Also, is this the proper way of pointing out issues? There are a bunch more (not as critical) I would like to address.

Thanks,

5

latest feedback of this is team is investigating and make sure all responses can return the weight usage.

Yes, for all API related issue, this is the best place to ask questions. Submit each of them in separate topic please.

6

Hi,

Just checking in on this issue as these endpoints still do not return a weight header.

Is the team still investigating? Can you provide a timeframe for resolution?

Thanks a lot!

7

I will forward this to the team again. Sorry for the inconvenience.

8

SAPI will not return the X-MBX-USED-WEIGHT header as it currently is using a different request rate limiting technique. X-MBX-ORDER-COUNT will be returned when an order is placed.

9

Can you direct me to the documentation that outlines this technique? I would like to add this rate limiting logic to my code.

Thanks,

10

The new SAPI rate limiting technique hasn’t been fully released yet. The public documentation will be updated when it is released.

11

Thank you Ninj0r!

1 Like
12

Hey @Ninj0r, just wondering if there has been any progress regarding the SAPI rate limiting technique since last time.

Thanks,

13

Sorry for the waiting, the team is working hard on tasks from higher priority. I will update here as soon as any feedback is available from the team.

14

I suggest to increase weight info in sapi, just like spot or future api.I need to precisely control how often I access the server through it.Thanks a lot.

15

it’s still in progress, hope it will be released soon.

thank you for your patience.