| Time | Status | User Agent | |
|---|---|---|---|
Retrieving recent requests… | |||
Reports the state of a single processing session, and how many items it has available.
This is a single endpoint shared across the ESG API. Whichever module produced a session, you poll it here.
When to use it
To watch progress cheaply. Where a request returned processing, this endpoint tells you whether the item count has moved without transferring any data.
To separate waiting from fetching. Poll here while a session runs, and go back to the module for the data only once the count shows there is something worth fetching.
Read-onlyThis endpoint never starts processing and never changes anything. Polling it has no effect on the data held for a company.
Getting a session id
You never construct one. The company request returns the id of the session working on it, as active_processing_session, while a processing session is in flight. In every other state the field is null, because no session is running.
Capture it from a processing response if you intend to poll.
A typical sequence:
| Request | What comes back |
|---|---|
GET /esg/v1/companies/{veridion_id}/news | status: processing, along with the active_processing_session to poll. |
GET /esg/v1/processing/{active_processing_session} | status: processing, result_count: 43 |
GET /esg/v1/processing/{active_processing_session} | status: complete, result_count: 48 |
GET /esg/v1/companies/{veridion_id}/news | status: complete, with the articles in result, and active_processing_session back to null. |
Response
A successful request returns 200 OK. The path carries neither a company nor a module, so the response echoes both: a session id alone is enough to know what you are looking at.
| Field | What it holds |
|---|---|
veridion_id | The company this session was opened for. |
module | The module that produced the session: news, commitments, or scores. |
status | The state of the session. See Response states. |
result_count | How many items are available. This mirrors what the module's own request would return, so it means something slightly different per module. See below. |
What result_count covers
result_count covers| Module | What is counted |
|---|---|
| News | Every article held for the company, including those gathered before this session. |
| Commitments | The commitments produced by this session, since a run replaces the previous set rather than adding to it. |
| Scores | 1 once a score exists, 0 before that. |
No filters apply here, so for News and Commitments this count can exceed what a filtered request returns.
A rising count is progress, not completionFor News and Commitments, items are counted as they arrive rather than all at once when a session ends, so the number climbs while a session runs. There is no guaranteed rate, and a count that has not moved for a moment does not mean the session has finished. A score arrives whole, so its count moves from
0to1in a single step.Use
statusto determine completion, and the count only to judge whether there is enough to work with.
Response states
status | Meaning |
|---|---|
processing | The session is still running. |
complete | The session ran to completion. It may have produced items, or none. |
not_found | The company was not found in Veridion's data sources. |
These three values are the whole vocabulary, and they match what the module's own request reports for the same session.
Error responses
400 Bad Request, whereactive_processing_sessionis not a valid UUID.404 Not Found, where no session exists with that id. This is the only 404 condition, since the path carries nothing else to validate.
Other standard HTTP error responses are detailed in the Response codes section.