AI metadata extraction for repositories: a complete guide to MetaExtract API

What a metadata extraction API is

An API (application programming interface) lets two systems talk to each other without a person in the middle: one sends a request, the other returns a response in a format both understand. With MetaExtract API, the request is a PDF and the response is its metadata, already identified and organized field by field.

The difference from generic text-extraction tools is interpretation. MetaExtract API does not just read the content of the document; it uses language models to understand what role each fragment of text plays in the structure of an academic or institutional document. It can tell a title from a subtitle, separate authors' names from their affiliations, and recognize where an abstract begins and ends even when the document does not label it.

Which fields AI metadata extraction returns

The field set is trainable to each institution's metadata schema, but in practice it consistently covers:

• Title and, when present, subtitle.
• Authorship: each author's name and, when the document states it, their institutional affiliation.
• Abstract, identified in the body of the document even when it is not a separate, labeled section.
• Keywords, both those declared by the author and those the model can suggest from the content.
• Date of publication or deposit.
• Document type (thesis, article, report, conference paper and others), which helps route deposits into the right collection of a repository.
• Language of the document.
• Local fields your institution defines: academic program, thesis advisor, project number, funding call code, academic unit, extent, identifiers or any other element of your schema.

That last point separates a generic extraction from a useful one. MetaExtract API is trained on real documents from each institution so that its output matches that institution's schema, not a standard template someone has to rearrange by hand afterwards.

How the integration works

In practice, the workflow has four moments:

1. Model training and connection. Extraction is tuned with real material from the institution (theses, articles, reports) so it recognizes local document types and fields, and it is connected to the target system or repository.
2. Document upload. The PDF is sent to the API, either because someone uploads it in the deposit workflow or because the institutional system sends it automatically when a document is deposited.
3. Recognition and categorization. The API identifies the requested metadata and organizes it according to the agreed schema: Dublin Core, local fields or both.
4. Auto-fill. The extracted data fills the description form of the target system automatically, ready for review before anything is published.

Input is the PDF; output is a set of structured metadata delivered straight to the form or workflow of the receiving system, with no intermediate file that someone has to upload again by hand.

For historical collections, MetaExtract API also works in batches. The sensible approach is to process by collection or by document type and review each batch before moving to the next, rather than loading everything and reviewing later. A repository filled quickly with unreviewed metadata ends up costing more to correct than one loaded carefully.

How accurate it is, and what your team still reviews

No automatic extraction system gets every field right in every document, and BiblioLabTech does not promise it. Confidence depends on the PDF and on the field:

That is why the workflow always includes human review before a record is published. The librarian receives a structured proposal and applies judgment where the machine cannot decide: normalizing names against the institutional authority file, assigning thesaurus descriptors, and making license and access decisions. The goal is not to remove review; it is to reduce it to the cases that really need it. It is also why validation against a control batch is part of every project, not an extra.

Which systems MetaExtract API integrates with

MetaExtract API is designed to join the infrastructure you already have, not to replace it:

In BiblioLabTech projects, this multi-system compatibility solves the hardest scenario to automate: a library that runs two different platforms, say a repository and a catalog, and needs to cut transcription in both without merging them into a single system, which would be a project of a different scale and is almost never on the table.

DSpace and Koha are free software maintained by their communities (dspace.org and koha-community.org), and OJS is developed by the Public Knowledge Project; MetaExtract API is a BiblioLabTech service that connects to them. The institution needs no new infrastructure, because MetaExtract API is delivered as a service. Someone on the IT team, or the repository provider, handles the integration, and the library defines the target metadata schema and the review procedure. In DSpace repositories that BiblioLabTech operates, the integration is our job.

Who AI metadata extraction is for

MetaExtract API makes most sense for three kinds of institution:

• Institutional repositories with a steady flow of deposits. Universities that receive theses, articles and reports continuously, where manual description becomes a bottleneck that grows every semester.
• Libraries with an accumulated digital backlog. Collections of PDFs already gathered (digitized holdings, historical institutional output) that were never described for lack of staff.
• Institutions running more than one platform. Repository plus catalog, or repository plus journal system, where one trainable extraction tool avoids maintaining two separate manual workflows.

It does not make sense when document volume is low and sporadic. Training and maintaining an integration like this is justified only when there is a constant flow of material to describe; otherwise, manual description remains reasonable. If you are still planning the repository itself, start with our overview of the institutional repository and what it takes to run one.

MetaExtract API vs BiblioScan AI

The two are often confused because both automate cataloging with AI, but they start from different sources and solve different problems. MetaExtract API reads digital documents (PDFs) and is built for repositories and document description. BiblioScan AI reads photos of physical material and is built for cataloging print collections, auto-filling MARC21 fields; our step-by-step guide to AI cataloging covers it in detail. When BiblioLabTech implements both for one library, it is almost always because the institution has both fronts, a print catalog and a digital repository, and needs to automate description in both.

Four universities, four system combinations

• Universidad ICESI (Cali, Colombia) integrated MetaExtract API into its existing infrastructure without changing systems or migrating content. Its information management team moved from transcribing every document to reviewing a proposed record, and the service has been renewed for consecutive terms.
• Universidad Católica Luis Amigó (Medellín, Colombia) integrated it into two platforms at once, its DSpace repository and its ABCD catalog, and has run it in continuous production since October 2024, with the contract renewed for a second year. It later added BiblioScan AI for physical material.
• Universidad Continental (Peru) implemented it on a commercial library platform the institution had already chosen, with no migration.
• Universidad Americana (Paraguay) integrated it into the deposit workflow of its DSpace repository from launch.

Four institutions, four different system combinations, and one pattern underneath: the API fits around what already exists.

Timeline, languages and cost factors

A typical MetaExtract API project takes six to nine weeks from assessment to production, and less when the institution already has its metadata schema defined and documented. The phase that varies most is tuning to the institution's own document types.

MetaExtract API processes documents in English, Spanish and Portuguese and returns metadata in the language of the document. For multilingual collections, it can extract titles and abstracts in two languages when the document includes both. Documents are processed for the purpose of extracting their metadata, and treatment, retention and deletion conditions are agreed in the contract, a point settled before implementation for institutions with strict policies on unpublished documents.

MetaExtract API is contracted as an annual service license that includes the initial implementation, tuning to the institution's fields, support and improvements during the period. There is no single price: the factors that move it are the number of schemas or document types to support, the integrations required and the expected processing volume. Every DSpace implementation by BiblioLabTech includes MetaExtract API at no extra cost, because a new repository almost always launches with an accumulated collection to describe; our guide to DSpace implementation cost covers the platform side. MetaExtract API can also be contracted on its own for existing repositories, including ones BiblioLabTech did not implement.

How to get started

When BiblioLabTech implements MetaExtract API, the sequence is always the same. First, survey the target metadata schema: mandatory fields, applicable vocabularies and the document types to distinguish. Second, train extraction on real documents from the institution, never on a generic sample. Third, process a control batch and compare it field by field with the description produced by your own team, the only baseline that makes sense. Only then does the workflow open in production, with the human review procedure agreed before any record is published.

If your repository or catalog receives more documents than your team can describe by hand, the next step is to review your metadata schema together. Contact BiblioLabTech with a sample batch of PDFs and your current schema, and we will tell you how quickly extraction can be trained on your real material.