Teleport audit event forwarding: avoiding duplicate writes on retries

Goal

Determine how to guarantee that audit events forwarded from Teleport to an external sink are not duplicated when the Teleport backend retries delivery after a transient failure.

Constraints & Uncertainty

• Teleport’s audit sink delivery is documented as at‑least‑once – retries are automatic but no exactly‑once guarantee is enforced.
• The platform emits a stable event identifier, yet Teleport does not provide built‑in idempotency for the downstream consumer.
• Deduplication responsibility falls on the integration or the external system, potentially varying by sink type and Teleport deployment.

Specific Questions

• Does Teleport expose a stable, unique event ID that can be used by the external sink to detect duplicates?
• Is there a configuration option or an upcoming feature that would switch audit event delivery from at‑least‑once to exactly‑once semantics?
• What recommended patterns exist for downstream services to safely deduplicate audit events received from Teleport?