Tellby Detect The Bet Docs
Reference

Verifying a release

Every release is cryptographically signed. You verify it against a public key you have pinned, entirely on your side, before it loads. This proves the release is authentic (published by us) and untampered. If it does not verify, it does not load.

The trust root

When you onboard, you pin our public key. That pinned key is your trust root: it is the one thing you check every release against. We publish the key fingerprint so you can confirm you have the right key through a separate channel, not just the delivery point.

Verify a release by hand

A standalone script is included with every delivery. Point it at any release to confirm the signature before you rely on it.

shell
sh verify/verify.sh feed-current.json
OK: signature valid, feed is authentic and untampered.

# on any mismatch it fails loudly and non-zero:
FAIL: signature did not verify. Do NOT load this feed.

The client verifies automatically

You do not have to remember to check. The reference client verifies the signature over the exact bytes it is about to load, before parsing, on every load and every refresh. There is no gap between what is authenticated and what runs.

Fails closed

An unverified release never enters your authorization path. If a release fails verification, the client refuses it and keeps serving the last good one. A tampered or corrupted update cannot reach your decisions.

Tamper-evident history

Beyond signing the current release, the full history of how each merchant was classified is recorded in an append-only, hash-chained log. Editing any past entry breaks the chain, and the chain state is sealed into every signed release. So the signature you verify vouches not just for today's list, but for the entire record behind it, which matters when your compliance team needs to reconstruct why a decision was made.