Integrations
Koha Integrations — Connect It to What You Already Run
Self-check, single sign-on, payments, e-resources and your student records — joined to the catalog instead of sitting beside it.
Sound familiar?
The catalog works. It just does not talk to anything.
A library system on its own is an island, and every island costs someone a manual step — usually the same person, every week.
“Students have a university login and a separate library login.”
“We bought self-check machines and they sit unused.”
“Fines can only be paid in cash, at the desk.”
“Our e-books are in a different system nobody searches.”
What connects
Six things libraries ask us to join up
Each is a separate piece of work with its own quote. Nobody has to buy all six, and most libraries start with one.
Self-check and RFID, over SIP2
Self-check units, RFID pads, security gates and sorters connect over SIP2 — the protocol they already speak. Existing hardware is usually a configuration job rather than a replacement. Deeper detail is on the RFID page.
Single sign-on — LDAP, Active Directory, SSO
Patrons sign in with the credentials they already have, and nobody maintains a second password list. An account disabled centrally is disabled in the catalog, which is what matters at the end of an academic year.
Online fine and fee payment
A payment gateway connected to the patron account, so a fine can be paid from a phone and the balance clears itself. Which gateway is possible depends on your institution and where it banks — this one we scope rather than promise.
E-resources and discovery
Records loaded from your e-resource providers, and a discovery layer or link resolver in front of the catalog so patrons search print and electronic together instead of learning two systems.
Patron records from your student system
New students appear as patrons and leavers are expired, from a scheduled import out of your SIS or HR system — instead of a spreadsheet somebody re-types every September.
Anything else, over the API
A REST API for the systems that are not on this list: a university portal, a room-booking tool, a reporting warehouse. Usually possible; the question is effort, and we would rather scope it than say yes in general.
How it fits together
One catalog in the middle, not six copies of your data
Every integration reads and writes the same records. The failure mode we are avoiding is the one where a patron exists in three systems and is right in none of them.
Before you ask us
What we can promise, and what we have to look at first
The difference matters, because half of any integration lives in a system we do not control.
Answerable now
- If your hardware speaks SIP2, it connects. Almost all of it does.
- LDAP, Active Directory and standard single sign-on are supported.
- Records import and export as MARC21, ISO 2709, MARCXML and CSV.
- There is a REST API, and you can build against it yourself.
Needs a look first
- Which payment gateway — it depends on your institution and its bank.
- What your e-resource providers actually expose, and in what format.
- Whether your student system can export on a schedule, or only on request.
- Hardware old enough to predate SIP2, or locked to one vendor’s software.
We hold no vendor partnership or certification, and do not claim one. What we can say is which protocols are supported, which is the thing you can check without taking our word for it.
Hardware specifically
RFID has its own page
Tagging, gates, pads, sorters and what a rollout actually costs in staff time — it is a bigger subject than one card on this page.
FAQ
What libraries ask about integrations
Will our self-check machines work with Koha?
If they speak SIP2 — and almost all of them do — then yes. SIP2 is the protocol self-check units, RFID pads and security gates already use, so the question is normally configuration rather than replacement. Tell us the make and model and we will tell you before you commit, not after.
Can patrons sign in with their university accounts?
Yes — through LDAP, Active Directory or single sign-on, so students use the credentials they already have and nobody maintains a second password. It also means an account that is disabled centrally is disabled in the catalog, which is the part that matters at the end of an academic year.
Can patrons pay fines online?
A payment gateway can be connected so fines are paid from the patron account and the balance clears automatically. Which gateway is available depends on your institution and where it banks, so this is one we scope rather than promise in general.
Can we connect our e-resources and discovery layer?
Yes. Records can be loaded from your e-resource providers, and a discovery layer or link resolver can sit in front of the catalog so patrons search print and electronic together. What varies is what your providers expose, which is the first thing we check.
What if the system we need to connect is not on your list?
There is a REST API, and most institutional systems have one too — so the honest answer is that it is usually possible and the question is effort. We would rather scope it and tell you a number than say yes to everything on a page.
Related reading
The technical background
How SIP2 actually works
What the protocol does, what it cannot do, and why almost all library hardware speaks it.
Read the guideRFID and Koha
Tagging, gates, pads and sorters — what connects, and what a realistic rollout looks like.
Read the guideUnion catalogs
Searching across several libraries at once, and what that needs from each of them.
Read the guideOther services
Get a quote
Tell us what needs connecting
Name the other system — the make and model, or the vendor — and we will tell you whether it connects before you commit to anything.