DentSignal engineering case study · FastAPI / webhooks

Retries needed identity. Callbacks needed one purpose.

Events without provider IDs were harder to deduplicate, while one short token lifetime could not safely cover both immediate WebSocket admission and delayed callbacks.

Area: FastAPI, HMAC, webhooks, idempotency
Evidence: Historical PR-reported validation
Boundary: No keys, payloads, or compliance claim

Plain English

Name each event. Limit each key.

What broke
An event without an ID could slip past ordinary duplicate checks, and delayed callbacks outlived the token used for immediate admission.
What changed
Missing IDs received a stable fallback fingerprint, while callback tokens were bound to one route, one resource, and their own lifetime.
Why it matters
Retries become safe to recognize without widening the short trust window used by the live WebSocket connection.

Simplified repair

Separate event identity from token purpose.

Broken · simplified example

event_key = provider_event_id
token = issue_token(ttl="short")

dedupe(event_key)
use_for_socket_and_callback(token)

A missing ID weakens deduplication, and one token is stretched across two different risks.

Fixed · simplified example

event_key = provider_event_id or fingerprint(payload)

callback_token = issue_token(
    scope="callback",
    resource=call_id,
)

Every event has stable identity, and the callback token is limited to its job.

Illustration only — not copied from private source.

How it was checked

Historical PR-reported validation

The cited history reports the full backend test directory, TypeScript, ESLint, build, and secret audit for the event-identity work, plus 151 focused tests, Ruff, secret scan, and an external-service guard for token scoping.