Is the default sort order of the Jobs/Jobs endpoint guaranteed to be CreateDate descending? Is this

Sharath_1000

Could you please advise on the below?

Is the default sort order of the Jobs/Jobs endpoint guaranteed to be CreateDate descending? Is this behaviour documented anywhere as a formal API contract?

Is the OData $orderby parameter supported on the Jobs/Jobs endpoint? For example:

GET /RestApi/v1/Jobs/Jobs?$orderby=CreateDate desc
If supported, this would be the safer long-term recommendation as it makes the ordering explicit and deterministic, rather than relying on an implicit default.

Extremely long API response times when adding new Requests or getting all Job information.
[2026-08-26 05:29:53,364] INFO root - END - YAyA9SmuwBCpUhfCy66eop AMDL.O 20260825 - Request job took 14.990secs.
[2026-08-26 05:30:21,429] INFO root - BEGIN - YNtxoEumivte2sASBmFgmQ TOPW.Z 20260825 - Request job
[2026-08-26 05:30:24,244] INFO root - END - YNtxoEumivte2sASBmFgmQ TOPW.Z 20260825 - Request job took 2.815secs.
[2026-08-26 05:30:24,244] INFO root - BEGIN - YurrMhfbtD7Qq2Maovqdue HMYY.O 20260825 - Request job
[2026-08-26 05:30:26,467] INFO root - END - YurrMhfbtD7Qq2Maovqdue HMYY.O 20260825 - Request job took 2.223secs.
[2026-08-26 05:30:26,467] INFO root - BEGIN - YVFwoW8wQ5CowQiQ4hbqFR YBTY.O 20260825 - Request job
[2026-08-26 05:30:29,119] INFO root - END - YVFwoW8wQ5CowQiQ4hbqFR YBTY.O 20260825 - Request job took 2.651secs.
[2026-08-26 05:30:29,119] INFO root - BEGIN - Yz42r3B8uMrg67H4Gox96f XBOX.Z 20260825 - Request job
[2026-08-26 05:30:45,951] INFO root - END - Yz42r3B8uMrg67H4Gox96f XBOX.Z 20260825 - Request job took 16.832secs.

And this is just a single job getting requested. This never took more than 3-4 seconds, most of the time, 2 seconds.
We are using Extractions/ExtractRaw for this and do *not* wait for the result:
url = self.__base_url / "Extractions" / "ExtractRaw"
headers = {
"Prefer": "respond-async, wait=0",
"Content-Type": "application/json; odata=minimalmetadata",
}

What is even worse - listing jobs:
We are iterating Jobs/Jobs and it takes 6-7 minutes to iterate. This definitely never took that long. We will try to improve our iteration (if we can ensure descending order from the API) to stop iteration, but also need your end to figure out why that APIs suddenly broke down in that manner.

Jirapongse

@Sharath_1000

Thank you for reaching out to us.

I have summarised the client's query into three questions:

1. What is the order of data returned in the /Jobs/Jobs endpoint response?
2. Does the /Jobs/Jobs endpoint support the orderby feature?
3. What are the performance characteristics of the /Jobs/Jobs endpoint?

For the first two questions, I could not find any information in the documentation that confirms the behaviour of the /Jobs/Jobs endpoint. To verify these details, please contact the DSS or Tick History support team directly through LSEG Support.

For the third question, I conducted some tests on the /Jobs/Jobs endpoint. For a single job, the endpoint typically returns data within a few seconds.

However, retrieving the entire job list takes more than 10 seconds in my environment, even though the list contains only six jobs. It is reasonable to expect that the response time may increase as the number of jobs grows.

In addition, response times can be affected by several factors, including network latency, server load, and overall system traffic. To determine whether this behaviour is expected and whether there are any known performance limitations, please contact the DSS or Tick History product support team directly through LSEG Support.

Specifically, please ask them to confirm:

1. The order in which records are returned by the /Jobs/Jobs endpoint.
2. Whether the /Jobs/Jobs endpoint supports an orderby parameter or any equivalent sorting functionality.
3. The expected performance characteristics of the /Jobs/Jobs endpoint when retrieving the entire job list

When using the Extractions/ExtractRaw endpoint with wait=0, the request is processed asynchronously. In this case, you can use the polling URL provided in the Location response header to monitor the extraction job status.

Alternatively, you can extract the Job ID from the polling URL and use it to query the status of a specific job through the Jobs/Jobs('<job_id>') endpoint. This approach retrieves information for a single job rather than the entire job list and is generally more efficient when you already know the Job ID.