Instrument Lists are for when the instruments do not need to be fluid, that is, different on every extraction. And there are 2 additional aspects of Instrument Lists that are possible directly with the REST API: by calling Validate and the passing the validated results to each request (as opposed to identifiers):

• Instrument Lists can be re-used across different report templates.

• Instruments Lists are pre-validated.

But then also note, because of the above, they can drift out of scope as the instrument universe changes, especially for things like a T-Bill issuance, and so periodic re-validation may be required.

If the instruments change significantly from extraction to extraction, then making them into an Instrument List beforehand will not help (it is basically what the On Demand extractions do under the covers). But you could manage your own collection of validated instruments (which too would need to "account for universe drift") and send in the validated instruments of interest on each request.

If the list is mostly static with only a few small edits between extractions, then using an Instrument List will help.

This is also true of the report template and even Schedule if a regular schedule is usable for the client’s purpose. For instance, if the need were "once-a-day pricing on a fixed list of instruments at 18:00 UTC each workday", then a reoccurring schedule referencing a saved Report Template and Instrument List will get those files generated the closet to 18:00 physically possible each day, then one would just use the API to come some-time-after-that and pick up the files.

There is no right answer, Datascope Select and the Datascope Select API have been designed to allow a wide variety of use cases to serve a very wide audience.

Both SOAP and REST for DSS are not particularly timely APIs. If you want lower latency queries I would recommend weekly downloads of instrument lists say by market venue id and relaying this cached snapshot as a micro-service.