Add a Stat Group When Creating a Patron API Key for Vendors
This proposal suggests enhancing the Patron API key creation process by incorporating a Stat Group field, allowing staff to categorize API keys by vendor and track their usage using existing reporting tools. The proposed enhancement would modify the API key creation window to include an optional Stat Group field towards the bottom. If left blank, the default stat group (zero) would be assigned, maintaining current functionality. This change addresses a common issue where vendors do not implement the stat group provided by the library, often resulting in API-driven transactions being categorized under stat group 0. This leads to inaccurate or inflated statistics, which is particularly problematic when the library intends to track circulation usage via the API but cannot do so effectively.
To expand tracking capabilities, it would also be beneficial to explore the feasibility of retroactively assigning a Stat Group to existing API keys. The implementation of this feature could leverage the workflow used for SIP2 license logins as a model for designing the Stat Group selection process when creating new API keys. Additionally, hold requests currently store the stat group within the body of the request rather than in the URL. Understanding this distinction may help in designing the stat group functionality for API keys in a way that aligns with existing data structures and workflows.
The implementation of this proposal would provide several benefits. It would enable staff to categorize API keys by vendor, allowing more precise tracking and facilitating data collection and reporting using existing tools such as Web Management Reports and Decision Center. It would also improve visibility into vendor-specific API key usage, supporting data-driven decision-making and reducing reliance on stat group 0 as a catch-all category, ultimately leading to more accurate circulation statistics.
This enhancement would streamline reporting efforts and provide better insights into vendor-specific API key usage, ultimately improving resource management and decision-making processes.
Victor Zuniga
shared this idea
The product team will review this idea for consideration for a future release.
-
Nicole Turzillo
commented
Just like Jeremy's consortium, we have vendors that use a single key for multiple libraries. Consequently, while the API endpoints will need a stat group parameter for data separation, it would be a significant improvement in usability if the stat group could be assigned as a default to the key.
-
Ray Voelker
commented
I'm very much in support of this approach -- adding the stat group to the key to be used as a default value makes it easier for everyone
-
Victor Zuniga
commented
Thanks for the clarification, Jeremy. Yes, we want to maintain the existing stat group parameter. If a vendor does not implement the provided stat group code, this will serve as a backup plan to keep track of their usage on the system via the Patron API. Thanks!
-
Jeremy Goldstein
commented
I mostly like this a lot, just treat the API key as a user account, similar to how stat groups are assigned to users in Sierra. The only point of clarification I would put out there is I would still want some of the API endpoints to include a stat group parameter as well so that it is possible to use a variety of stat groups in some circumstances. For example our mobile app has a self checkout feature that needs to use a different stat group for different locations within our consortia. We would still like to issue a single API key to the support vendor for administering that. But in that case even it would still be useful to provide a default stat group other than 0 for the key, and just allow that to be overridden by an implicit stat group parameter as part of an API call.