Deduplicating candidates when a platform redelivers the same event

The HR platform receives candidate responses from several external job platforms and brings them into one hiring process. Every event from a platform carries an identifier, and the most obvious first line of defense against duplicates is to check that identifier before creating a candidate.

An event identifier only protects against the same event being redelivered. It does not protect against a platform sending a new event — with a new identifier — for the same candidate: for example, the candidate updated their resume, or the platform resent the response after an outage on its side. Checking only the event ID in that case creates a second candidate in the system with the same history and contact details.

Candidate deduplication also checks for a matching candidate by contact details — if a candidate with the same contacts already exists, the new event attaches to them instead of creating a duplicate record.

A similar problem shows up in messaging: an outgoing operator message does not always get a platform identifier right away, and the candidate may write again in the meantime. To avoid a duplicated thread, an outgoing message is "adopted" once the platform confirms it, instead of creating a new record for it.

And if an event genuinely cannot be processed right away — for example, the vacancy has not synced from the platform yet — it is not discarded, but stored in full and can be replayed later.

A duplicate candidate in hiring is not just an extra row in a table: it is a broken conversation and status history, which can mean a recruiter messages the same person twice or loses the context of an earlier conversation. Deduplicating by the business meaning of the event — the candidate — rather than only by its technical identifier is what makes an external integration reliable instead of "working on average".