Permit due date extension via the API
Currently the only way to extend item due dates is to run Rapid Update on a review file of those items. I would like to be able to programmatically update due dates via the API. I see two potential benefits of this feature:
Benefit 1: Rapid Update prompts for a single absolute date to apply to a group of items in a review file. There have been many times when we have wanted to extend the due dates of a group of items by "n days", regardless of their current due date. It would be straightforward to write a Python utility to act on a review file of checked-out items, adding n days to their due dates.
Benefit 2: Outside of Tech Services, Collection Development and a tiny handful of individuals, Create Lists/Rapid Update is not open to use by anyone in a branch. Our Mobile Services (Bookmobile) department frequently needs to extend due dates on items to match their route schedule. If they miss one or more mobile stops due to weather, traffic, staff availability, bus maintenance, etc, it might be another few weeks before they are able to get back out to those stops. Currently the task of extending due dates falls in my lap, and the most recent request involved almost 40 different stops, each with their own stat group and a variety of new due dates to apply. An API endpoint capable of extending due dates would permit me to build a web interface for Mobile Services to empower them to change their own due dates more promptly than they can make the request of me and more promptly than I could act upon it.
Bob Gaydos
shared this idea
-
Victor Zuniga
commented
_
This would address a real operational gap between what staff need to do at scale and what the current API allows.
I can see this enhancement addressing the following:
Reduced risk compared to Rapid Update
Rapid Update is powerful but blunt. It applies a single absolute date and leaves little room for logic, validation, or preview. An API-based approach would allow guardrails such as:- extending by n days relative to the current due date
- validating item status and checkout state before applying changes
- logging every change with item ID, patron ID, old/new due dates, and staff attribution
This actually reduces risk, especially for large or complex batches.
Delegation without over extending permissions
Many departments (Mobile Services, Outreach, Branch Ops) legitimately need to manage due dates, but granting Create Lists / Rapid Update access is often inappropriate. An API endpoint enables purpose-built interfaces with limited scope and role-based permissions, which is far safer than expanding Sierra permissions.Scalability and consistency
When dozens of routes, stat groups, or schedules are involved, manual workflows do not scale. Programmatic extensions ensure consistency across items and reduce the chance of human error, especially when multiple different due dates are required.Parity with modern ILS expectations
Due date changes are a core circulation function. The absence of an API mechanism for adjusting them stands out as a significant limitation compared to other circulation actions that are API-enabled (renewals, holds, fines, blocks, etc.).This enhancement would unlock responsible automation, empower frontline teams, and reduce administrative bottlenecks, without weakening data integrity. It’s exactly the kind of API capability that lets libraries meet real-world operational needs while maintaining appropriate controls.
-
Jeremy Goldstein
commented
I can absolutely see the value in writing a script to make these sorts of adjustments when necessary.