External participant sync API: an athlete database without manual duplication

For many federations and large organizers, the athlete database doesn't live only in the registration system. There's the federation's records system, there's a CRM, there are historical lists — and they're all about the same people. Keeping these databases in agreement used to mean moving participants by hand: copying, cross-checking, catching duplicates. We removed the manual labor. scoreio gained an external sync API for the athlete database with outside systems — participants are transferred automatically, and duplicates are filtered out by a clear rule.

How it used to be

When the same participant database is kept in two places, there's always a gap between them. The federation registers a new athlete — the registration system doesn't have them yet. An athlete from a tournament appears in registration — the external database doesn't know about them. To reconcile, someone sat down and moved records by hand: export from one system, manual entry into another, cross-checking against a list.

This isn't just slow — it's a source of duplicates. The same athlete was easily created twice: somewhere with a typo in the surname, somewhere with a different spelling of the name. The database swelled with "doppelgangers," participation statistics blurred across copies of one person, and the only way to fix it was another manual cleanup. The larger the organization, the more expensive this gap between systems became.

Duplicates are not just cosmetic untidiness. Everything that relies on the participant database suffers from them. One athlete's competition history splits into two halves and never comes together whole. Any analytics on the number of unique participants comes out inflated. And when the same person shows up at the next event, the operator again isn't sure which of the two records is the "real" one, and often creates a third. So one unsolved problem breeds the next, and over time the database loses trust — people use it, but with the caveat "you have to double-check it there."

Manual transfer is also bad because it doesn't scale with the organization. While there are a hundred athletes, someone heroically keeps two databases in agreement. When there are thousands and they change every week, manual reconciliation simply can't keep up with reality: by the time you've reconciled the lists, they've diverged again. What's needed isn't one-off heroics but a permanent automatic channel — and that's exactly what was missing before.

What changed

We opened an external API through which scoreio's athlete database can be synced with outside systems automatically. It's a dedicated programmatic entry into the platform: an external system calls it and passes participants, and scoreio accepts them by clear rules — without manual transfer and without breeding duplicates.

A programmatic entry point

A dedicated external API controller appeared — the point through which outside systems communicate with the athlete database. This means a federation's records system or a CRM can pass participants into scoreio programmatically, not through exports and manual entry. The integration stops being a one-off "export-import" and becomes a permanent sync channel.

Key-based authorization

Access to the external API is protected by an authorization key. Only a holder of that key can pass participant data. This keeps the sync controlled: the channel works for trusted systems and is closed to everyone else. It's a basic but important condition when it comes to athletes' personal data.

API documentation

So the integration can actually be implemented, the external API has documentation. The external system's team sees how to call the API and in what form to pass participants — and connects by the spec rather than by trial and error. A documented interface turns "let's somehow hook up" into a predictable integration project.

Deduplication by name and birth date

The most valuable part is the upsert and deduplication algorithm. When a participant arrives via the API, the platform doesn't create them blindly: it matches the athlete by full name and birth date. If the person already exists, the record is updated; if not, a new one is created. That's how upsert works — "update or insert." This rule is exactly what keeps the database from swelling with duplicates: the same athlete stays a single record, even when they come from an external system again.

Why full name plus birth date? Because this combination is stable enough to recognize a person across transfers, yet doesn't require the external system to know scoreio's internal identifiers. The external database sends what it already has about the athlete, and the platform itself decides who it's looking at — a new participant or a familiar one. Thanks to this, the sync can run as many times as you like: a repeated transfer doesn't breed copies, it simply updates what changed and adds those who weren't there yet.

This is the difference between an "import" and a "sync." An import is a one-time pour, after which the databases immediately start to diverge. A sync with upsert and deduplication is a process you can repeat regularly, keeping the athlete database in constant agreement with the external source and accumulating no junk.

What this gives you

• No manual duplication. Participants are transferred via the API rather than copied by hand between systems.
• A database without doppelgangers. Deduplication by name and birth date keeps one athlete as one record.
• A link to outside systems. A federation's records database or a CRM syncs with scoreio as a single source of participants.
• Controlled access. The sync is protected by an authorization key — the channel is open only to trusted systems.
• Predictable rollout. A documented API lets the team connect by the spec rather than by guesswork.

Scenarios where this solves the problem

A federation keeps an athlete records database. The federation has its own member-records system, and the same people register for competitions in scoreio. Through the external API, the records database syncs with the platform: new athletes land in scoreio automatically, and deduplication by name and birth date prevents creating them again.

Integration with an organizer's CRM. A large organizer keeps participants in a CRM and doesn't want to duplicate the same work in the registration system. The external API becomes a bridge: participants from the CRM are passed into scoreio programmatically, upsert updates existing ones and adds new ones — no double entry.

Regular participant import. Databases change constantly: someone joined, someone's details were corrected. Instead of periodic manual exports, the external system calls the API and keeps the athlete database up to date, while deduplication guarantees that repeated transfers don't breed copies.

Frequently asked questions

What exactly does the external API do? It lets outside systems sync the athlete database with scoreio programmatically: pass participants and keep databases in agreement without manual transfer.

How does the platform tell a new participant from an existing one? By full name and birth date. If such an athlete already exists, the record is updated; if not, a new one is created. That's upsert with deduplication.

Won't duplicates appear on repeated syncs? No — that's what deduplication is for. The same athlete, by name and birth date, stays a single record no matter how many times the external system passes them.

How is API access protected? By an authorization key. Only a system holding the key can pass data — the channel is closed to everyone else.

Is it hard to connect? The API has documentation: the external system's team sees how to call it and how to pass participants, and connects by the spec rather than by trial and error.

How is a sync different from a plain import? An import is a one-time pour of data, after which the databases start to diverge again. A sync via the API with upsert and deduplication can be repeated regularly: the athlete database stays in constant agreement with the external source, and repeated transfers don't breed duplicates.

How to start

Setting up the sync means obtaining an authorization key and integrating the external system per the API documentation. From there, the athlete database stays in agreement automatically: participants are transferred programmatically, existing records are updated, new ones are added, and duplicates are filtered out by name and birth date. Moving participants by hand between systems is a thing of the past.

Reliable sync rests on the rebuilt registration and payments core, and a unified participant database is especially valuable when each organizer works in its own space.

Want to link your athlete database to scoreio without manual duplication? Request a demo or a pilot launch of scoreio — we'll show how the external API syncs participants and filters out duplicates on your own data.