Hi @massinissa.bitous-ext,

The difference between GET and POST is documented in the API reference tab:

GET endpoints start processing the data and give the response once the 1st page is ready

POST endpoints give an ID and start processing the data in the background, so the user can return later to see the data using that ID

Basically, the POST method will price the whole chain first, and once fulfilled you can request the data using the cached-id parameter. This way, the chain constituents have market data for the same point-in-time.

When should I call the POST ? How long is the cache ?

The Post should be the first API call, and it will return the cached-id parameter in the header, which can be used in the GET call.

After how long should I update it recalling the POST method ?

Typically how these API work is by responding with a HTTP 202 status code and a link to check the status of the server process. Once the status code changes to HTTP 200; the data is ready on the server and can be retrieved. However, this is not happening with this endpoint, and it keeps sending HTTP 202 only. I will ask the product team to clarify about this.

I've seen that I can provide a page-size parameter when calling the GET method, with a default value of 10 and a maximum value of 100. Is it a good idea to make calls with a page-size of 100?
This way we limit the number of calls. By setting the page-size parameter to 100, I've noticed that the response is still quite fast, given that there's a cache system.

Use the maximum page size permitted.

Hello @Gurpreet ,

First of all, thank you very much for your answers.

I implemented the use of the API, but in the end I decided not to implement the POST call, as I didn't fully understand how it worked. What's more, you seem to be saying that it doesn't quite work as it should.

So I only use GET, I don't use the cache-id parameter, although GET also returns a cache-id header, but the cache seems to be used, even without using this parameter.

Once the GET has been performed on the first page, retrieving data from subsequent pages is much quicker. Or, if I try to retrieve that first page again, the response is very fast.

If you think this implementation is viable, I'll go for it.

Also, I've had some feedback from customer service regarding other requests: in particular the use of a quality of service filter (currently the api always returns the best quality of service to which I'm entitled, whereas sometimes I'd like to choose the quality of service). Apparently this is a feature that could be added.

Thanks again for your help.

Have a nice day.

Hi @massinissa.bitous-ext,

Yes, your approach is correct.

Currently there is no means within this API to specify the Quality of Service, and all pricing requests are fulfilled from the Wealth real-time service: ERT_FD3_LF1 - which is conflated at 3 updates per second.