Where did the PERCENT_PRICE filter in exchange info go?!

The documentation states:

The PERCENT_PRICE filter defines the valid range for the price based on the average of the previous trades. avgPriceMins is the number of minutes the average price is calculated over. 0 means the last price is used.

This was part of the exchangeInfo endpoint, but all of a sudden the endpoint stopped returning it. This change seems to have been introduced within the past day or two. However there is no mention of it anywhere - not in the change log nor in github (from what I’ve seen).

Is this a permanent change or a temporary issue?

PERCENT_PRICE_BY_SIDE is replacing this PERCENT_PRICE filter. Please use PERCENT_PRICE_BY_SIDE if it’s available from the symbol.

There is no statement that PERCENT_PRICE is going to be deprecated, obsolete, removed or replaced. I can’t “just switch” to using another filter – things are running in production and would require code changes.

Can you confirm PERCENT_PRICE is not coming back?

1 Like

as PERCENT_PRICE_BY_SIDE is the new filter, it’s required to follow this filter just like others.

Thanks for the confirmation.

I’d like to raise my concerns in regards to how these changes are being introduced into production.

  1. Binance profits from taxes of transactions. This profit comes from traders, institutions and people like me who develop trading software which relies on your APIs.

  2. Changes to the API are inevitable and this is understandable. However, removing features without notices is the worst possible thing you can do. This not only costs you money (no transactions = no taxes, because software depending on the API can’t work), but also opens you to lawsuits for malpractice since the introduced changes are neither announced nor a technical issue / bug.

The best practices / strategies when changes to the API are necessary are to:

  1. Announce the deprecation of a feature and the future date after which it will cease to exist. If there is a replacement feature – let people know what it is and how to migrate to it.

  2. Continue to support the deprecated feature until the future date occurs.

  3. Remove the feature.

  4. A bonus would be if you first deploy these changes into a “staging” environment (or Testnet) and then go into production.

This is what all of the well-established companies in the industry are doing (AWS, GCP, IBM Cloud, RedHat, Scaleway, etc). The reason for doing it this way is to allow customers to migrate in time and also to limit their exposure to any possible lawsuits due to missed profits because of the API changes.

I would very much appreciate it if you could please pass this to the respectful managers of the internal DevOps team which is responsible for releasing things into production.