Today, Sierra’s REST API does not provide a reliable way to retrieve a complete list of location codes (and their names/labels) as defined in Sierra’s Branches table (SDA: Admin > Parameters > General > Branches). This creates friction for discovery-layer implementations and other third-party integrations that require an authoritative, up-to-date list of locations.

Innovative Support shared that “it’s not possible to get a list of all locations using the REST API,” and that the closest option is the branches endpoint, which only returns locations that are linked to entries in the Branch Address table, not a full representation of the Branches table. Fiona (BiblioCommons) also confirmed the current Branches API is insufficient and has requested III improve it to return a full representation of the Branches table.

Current behavior

When calling:

GET /v6/branches/?fields=%2C

We receive only two branch entries and an API response showing:

"total": 2 (implying only two branch records exist), even though our environment contains many more branch/location entries in the Branches table.

The response includes a locations array, but only for locations linked to Branch Address table entries.

Example (truncated):

{
"total": 2,
"start": 0,
"entries": [
{
"id": 1,
"name": "Poudre River Public Library District",
"locations": [
{ "code": "adult", "name": "Adult" },
{ "code": "afic", "name": "Adult - Fiction" },
...
]
},
{
"id": 2,
"name": "Interlibrary Loan"
}
]
}

Desired behavior

Provide a REST API mechanism to retrieve a complete, authoritative list of:

All Branches table entries (not only Branch Address table entries that have names populated), and/or

All location codes as defined in the Branches table, including their display names/labels and other relevant metadata used by integrations.

Why this matters (impact and use cases)

This enhancement would significantly improve Sierra interoperability with third-party vendor products and local applications by enabling real-time retrieval of location configuration data.

Primary use case: Discovery layers

BiblioCore, Aspen Discovery, and Vega Discover (and similar products) need accurate location codes and labels to support:

facets and scoping

branch/location-based availability display

collection/location grouping rules

pickup location logic

suppression or “hidden” locations behavior where applicable

Right now, when a library:

adds a new location code,

renames a location display label,

retires/deprecates a location,

…they typically must manually communicate those changes to the discovery vendor (often via spreadsheets/emails/tickets). That adds delay, introduces errors, and makes “near real-time” configuration synchronization impossible.

Secondary use cases (beyond discovery)

internal analytics/reporting tools that want to label circulation/hold data by location

AMH/bin mapping, routing, or sorting optimization tooling

self-check, RFID, or third-party circulation peripheral integrations

custom staff apps and dashboards that need the live location dictionary for validation and display

Proposed solution options

Any one of these would solve the problem. More than one would be even better.

Option A: Enhance /v6/branches to represent the full Branches table

Return all branch/location records stored in the Branches table, not just those tied to Branch Address entries with names.

Add a way to request “Branch Address fields” separately (since Branch Address and Branches table are distinct concepts in practice).

Option B: Add a dedicated endpoint for locations

For example:

GET /v6/locations

GET /v6/branches/locations

Option C: Provide an “includeAll” style flag
If III wants to preserve current default behavior, add something like:

GET /v6/branches?includeAll=true

GET /v6/branches?source=branchesTable vs source=branchAddressTable

Improving access to the Branches table / locations dictionary via REST API would be a major interoperability win for Sierra. The main theme is discovery layer integration (BiblioCore, Aspen Discovery, Vega Discover), but the same capability would benefit many other integrations and local applications that need accurate, real-time location metadata.