How: Include the link id
property in the existing Inbound and Outbound link objects returned from fetchdata
. Example:
{
"id": 1234, // This would be the actual link ID
"entityId": 194866,
"summary": { ... }
}
Why: Currently, fetchdata
allows querying up to 1000 entities at a time. However, when working with links, you cannot retrieve the link IDs directly in this call. If you need the link IDs, you must make additional requests for each entity individually, which is very inefficient. Including the link ID directly would allow consumers to work with links (e.g. sorting, identifying, managing links) using the data already returned, without needing to make secondary calls.
For Who: Any API consumers using the REST API who need to process links at scale without making per-entity link requests.
Impact: This change would significantly improve performance for any bulk operations involving links, reducing round trips, latency, and server load when working with larger datasets.
Additional context: While link summaries and related entity information are returned today, the link ID itself is missing, which limits downstream use cases that require the unique link reference. Adding this field would better align the REST API behavior with the link object structure available in other inRiver contexts (i.e. Remoting API).