Persons

Person records

GET /persons/{person_id} returns a natural person named in the register:

{
  "object": "person",
  "id": "per_01hxn3rys1fh58w4d1pb1x9s82",
  "name": { "full": "Erika Mustermann", "first": "Erika", "last": "Mustermann", "birth_name": null, "titles": [] },
  "birth_date": "1970-01-01",
  "birth_year": 1970,
  "birth_month": 1,
  "age": 56,
  "address": { "city": "Musterstadt", "country": "DE" }
}

The age in that example is as of 8 October 2026.

What the person does at companies is listed separately, from the person's side:

• GET /persons/{person_id}/roles — the offices they hold or held: managing director, board member, Prokurist, liquidator. Narrow it with role_type, or add expand=roles to the person request to get the first page inline.
• GET /persons/{person_id}/holdings — the interests they hold: shares, and Kommanditist interests in limited partnerships.

The same role and shareholding objects are listed from the company's side, at /companies/{company_id}/roles and /companies/{company_id}/shareholders. Each names the company and the holder as a party, so you can follow either direction.

How the score is assigned

The API does not compute match_confidence. It publishes a score stored when a register profile was linked to a person record.

Person endpoints, GET /companies/{company_id}/roles and a company's history publish that stored number only when it is a number from 0 to 1. A value outside that range is left unpublished, and match_confidence is null.

A company role is linked only when the register profile is visible and every stored match of that profile is a person who may be shown. If any match is a restricted person, no link is published: the holder has no person id and match_confidence is null. The API does not publish another match of that profile instead. When every match may be shown, the published score is the highest stored score for that profile.

More than one matcher has written that stored score, and they do not share one scale. A number is therefore not one level with one meaning across the whole dataset.

The batch function that wrote many of the rows stores only the scores below. A dated profile is linked to a person with the same birth date or the same birth year, or a new person is created. A profile with no birth date is the only case that stores 0.50.

Other jobs write other numbers into the same field:

• Reading a managing director, a Prokurist or a limited partner stores 0.80 with no further test.
• The matching container's batch script uses those same 0.95, 0.90 and 0.75 rules. It also stores 0.70 when only the last name and the full birth date agree, and 0.50 when the name matches and the birth date differs, or the match was by name alone.
• An older batch script is retired: nothing in the repository calls it. Rows it already wrote can still be published. It stored 0.95 for the name and the full birth date, 0.90 for the swapped name and the full birth date, 0.75 for the name and the birth year, 0.70 for the last name and the full birth date, 0.80 for the swapped name and the birth year, a name-only score of at most 0.50 that gets smaller as more people share the name, and 0.0 when no rule matched.
• Another writer starts from 0.90 and divides it by how many person records the profile is linked to.

Two equal scores can therefore come from different rules.

What to do with the score

• Show the score whenever you show the link. A published value is from 0 to 1, or the field is null.
• Do not auto-merge on the score. No matcher treats a value as proof that two records are one person. Confirm the name, the birth date and the city.
• Never merge a holder whose score is null. That holder is a company, no person was linked, or any match of the profile is a restricted person. On the batch function, 0.50 means the profile had no birth date. The day may differ at 0.75, a same-year match.

How reliable is match_confidence

Measured on 2026-10-14. Precision is the share of links whose register entry and person record read as the same person, among the links the register can decide. Undecidable is the share the register cannot decide, mostly entries without a birth date.

The undecidable links at 0.80 are entries without a birth date whose person was made from that one entry: such a link cannot join two people. At 0.50 the entry has no birth date and nothing else in the register ties it to the person.

Recommendation: use links with match_confidence ≥ 0.80; below that, treat the person link as a suggestion. In the sample, none of the 954 decidable links at 0.80 or above read as a different person.

Corrected on 2026-10-15. The 0.75, 0.70 and 0.60 rows above were measured before a correction: 605 links stored at those scores had a register entry that contradicted the linked person (another birth date or another last name). Each now points to the person with the entry's own name and birth date (0.95), to the person with first and last name swapped and that birth date (0.90), or to a new person made from the entry (0.95). What this means for you:

• No link is published at 0.75 or 0.70 any more. At 0.60, only links whose name and birth date agree remain.
• A role or shareholding of a corrected entry can now name another person id than before. A person id you stored for one of them may no longer list that role. Re-read the roles and shareholdings you cached before 2026-10-15.

Method. A random sample of 1,436 published links, drawn per score (every link at 1.00, 0.70 and 0.60), was read in two independent, automated passes that compared each register entry with its person record without seeing the score; the passes agreed on 97.8 % (Cohen's κ 0.941), and a third reading settled the 32 disagreements. Precision is same / (same + different) per score, with a 95 % Clopper-Pearson interval.

Two people with the same name and the same birth date cannot be told apart in the register, so no measurement here can see them. The readers saw the register as Registercheck stores it, not the original documents.

Matching is name-based, and names are not unique

A person here is "a named holder", assembled from register entries. Where the register gives a city and a date of birth, matching is reliable. Where it gives only a name — which is common in older entries — it is not.

Design for this:

• Do not treat a person id as an identity. Two Rolf Müller entries may be one human or two.
• Check address.city, birth_date and age before merging a person into your own records. age is whole years as of today in Europe/Berlin, computed from birth_date on each request and never stored. It is null when the date is missing, in the future, or the age would be over 120.
• Expect duplicates for common names, and expect a single human to appear under several ids across courts.

Privacy

Register data about natural persons is personal data. Some people have exercised their right to object, and their records are restricted: search, person records, roles and shareholdings never return them.

Personal data from this API is subject to the GDPR in your hands as well as ours. A lawful basis for processing it is yours to establish.