German HR Software API: Maintain Values, Don't Hardcode Them

What 'HR software with its own API' means

Many HR products now offer their own API, letting customers connect employee data, absences or master data. Inside the product, though, many features also need values that do not come from a customer at all, but from German law and public administration: public holidays by federal state (Bundesland), notice periods, statutory vacation entitlement, maternity leave rules (Mutterschutz) and the minimum wage. The product team has to maintain these values itself, separate from its own customer-facing API.

This touches very different features: an absence calendar that grays out holidays by location, an assistant that suggests a notice period while drafting a termination, an onboarding flow that enters maternity leave into the calendar automatically, or a pay calculator that checks the minimum wage. The solution page on public holidays, deadlines and leave for your HR software shows how HR products connect this in practice.

This article sorts the values, shows how often each one changes, and compares two ways to maintain them: by hand in code, or through an API, plus MCP for AI features that decide inside the product when they need a value.

Which values live inside HR software

• Statutory public holidays by federal state, including regional holidays such as Corpus Christi (Fronleichnam) in parts of Saxony.
• Notice periods (Kündigungsfristen) under Section 622 of the German Civil Code (BGB), depending on tenure and any probation period.
• Statutory minimum vacation entitlement under the Federal Vacation Act (Bundesurlaubsgesetz), pro-rated for part-time work or a mid-year start or end date.
• Maternity leave rules under Section 3 of the Maternity Protection Act (Mutterschutzgesetz, MuSchG), with special cases for premature birth, multiple births and, since 2025, pregnancy loss.
• The minimum wage and the mini-job earnings limit derived from it.

How often these values change

Not all five values change at the same pace or the same predictability. The minimum wage has risen nearly every year since 2022, usually on January 1, with several months of advance notice. Public holidays change less often, but sometimes with little advance warning at the national level, because each of Germany's 16 federal states has its own holiday law.

Two recent examples show this. Berlin had a one-time statutory holiday on May 8, 2025, marking the 80th anniversary of liberation, under Berlin's own law on Sundays and public holidays. Mecklenburg-Vorpommern has treated International Women's Day as a statutory public holiday since 2023, under its own state holiday law. Software that hardcodes holidays in its code can easily miss changes like these unless someone actively watches for new state legislation.

Deadlines change over time too. Since June 1, 2025, Section 3 MuSchG has set staggered protection periods after a pregnancy loss (Fehlgeburt) from the 13th week of pregnancy onward, two, six or eight weeks depending on timing. Before that date, the law did not address this case at all. HR software built before 2025 and never updated since may not cover it.

Notice periods and statutory minimum vacation, by contrast, rarely change in substance: Section 622 BGB and the Federal Vacation Act have stayed core-unchanged for decades. The risk here lies less in new values than in miscalculation, for example around when a notice period starts under Sections 187 and 188 BGB, or a part-time entitlement that is not pro-rated correctly.

Two ways to maintain these values

The first way enters values once into code or a configuration table and updates them whenever someone remembers to, usually through an annual ticket. That works as long as nobody forgets to check, and as long as the values are few and well known.

The second way queries values through an API, either at runtime when needed or once a year through a sync job into your own database. Each value arrives with its legal basis, its valid-from date, and, for notice periods or maternity leave, as a computed result for a specific case. Parameters and fields are documented on the reference page for the German notice period calculator.

The difference shows up in a support ticket. If a customer reports an incorrect notice period, an API response immediately shows the legal basis and the calculation. A table hardcoded in the source only returns the value, not where it came from.

The cost of manual upkeep is also easy to miss, because it spreads across many small moments: one ticket here, a support question there, a wrong answer during a new customer's onboarding. Added up, that is often more work than connecting to an API once.

Example values an HR product needs today

An example: from a spreadsheet to one query per federal state

Many HR products start with a spreadsheet or a list hardcoded in their code for public holidays, usually for a single federal state, because that is where the first customer happens to be. Once more federal states, more locations, or teams with employees across all of Germany join in, the spreadsheet grows faster than anyone maintains it.

That is the point where switching to a query by federal state and year pays off, instead of maintaining 16 separate tables. Bavaria has 14 statutory public holidays in 2027, for example, another federal state has a different count, and both figures come from the same query with a different state parameter.

For a product with customers across Germany, that is the difference between a feature that is correct for one federal state and one that is correct for all 16.

MCP for AI features inside the product

When a product team builds an AI-powered feature into its own HR software, such as a chat that answers questions about remaining vacation days or notice periods, a hardwired API call often is not enough. Here a language model needs to decide for itself when it needs a value and with which inputs, instead of following one fixed flow.

That is exactly what MCP is for. An AI agent inside the product gets tools such as hr_kuendigungsfrist or hr_feiertage from an MCP server, calls them as needed, and gets back a value, its legal basis and a ready-to-cite sentence, instead of guessing a number from training data. Setup and structure of the server are covered in the MCP server documentation.

A REST API and MCP are not an either-or choice. For deterministic features such as an absence calendar or a fixed pay calculation, a plain backend API call remains the simpler choice. MCP is worth adding where an AI feature inside the product decides the next step on its own.

Calculate a notice period for an HR software feature

$ curl "https://api.quellenkontor.dev/v1/hr/kuendigungsfrist?eintritt=2017-03-01&zugang=2026-11-10" \
    -H "Authorization: Bearer $QK_KEY"

# Excerpt of the response
{
  "frist": "3 Monate zum Ende eines Kalendermonats",
  "ende": "2027-02-28",
  "rechtsgrundlage": "§ 622 Abs. 2 Satz 1 Nr. 3 BGB"
}

The same value as a tool call for an AI agent

{
  "name": "hr_kuendigungsfrist",
  "arguments": { "eintritt": "2017-03-01", "zugang": "2026-11-10" }
}

// First text block of the result (result.content[0].text)
Gesetzliche Kündigungsfrist bei Eintritt am 01.03.2017 und Zugang der Kündigung am 10.11.2026, Kündigung durch den Arbeitgeber: 3 Monate zum Ende eines Kalendermonats, das Arbeitsverhältnis endet am 28.02.2027. Schematische Berechnung ohne vertragliche oder tarifliche Fristen. Rechtsgrundlage: § 622 Abs. 2 Satz 1 Nr. 3 BGB. Quelle: § 622 BGB (Kündigungsfristen bei Arbeitsverhältnissen), https://www.gesetze-im-internet.de/bgb/__622.html. Daten: Quellenkontor (quellenkontor.dev).

How product teams move from manual upkeep to an API

• Replace value tables in code or migration scripts with runtime calls or a periodic sync job.
• Store every value with its valid-from date in your own database, not just the current figure.
• Pass parameters such as federal state or reference date through consistently, instead of hardcoding one value for every customer.
• Set up a webhook or a scheduled query for new or changed values, instead of waiting for a support ticket.
• Connect AI features inside the product to the same set of values through MCP, so chat answers use the same source as the rest of the software.

Testing against known cases before a feature goes live

Before a new feature goes live, it is worth testing it against known cases: a notice period your own team can check by hand, a federal state with a known regional holiday, a maternity leave due date with a known start and end.

That surfaces early whether your software passes the right parameter, such as the federal state where the work is performed rather than company headquarters, or the date a notice was received rather than the date it was drafted. Small parameter mix-ups otherwise often only surface once a customer reports a wrong deadline.

Staying fair: when manual upkeep is enough

A product with very few, rarely changing values can run for a while on a table reviewed once a year, for example if only the nationwide public holidays are needed and no regional exceptions apply. A dedicated API connection pays off once several federal states, several kinds of values, or a feature that must answer live and with evidence come together.

A free key, no credit card required, is enough to get started: sign up for free.