# Consent, linking and revocation

Consent belongs to a signed-in BOT account, not a device installation. For one
reviewed integration/profile/purpose/scope version, the user selects one or more
specific orders and optionally specific stock vehicles. Statistics participation
is a separate per-integration opt-in for selected orders. New purposes or scopes
create a new consent version; old consent is never widened silently.

The ten-digit value shown by a future app is an integration-bound one-time code.
It preserves leading zeroes, expires after ten minutes, is stored only as a
peppered hash and succeeds exactly once. Only the matching integration's mTLS
client may redeem it. Redemption returns the already integration-specific
connection/resource IDs, never the BOT account or internal resource identity.
BOT accepts redemption only after the connection initial sync and every selected
active resource snapshot/history are complete. If a later grant has reopened the
sync cycle, redemption fails with the same opaque invalid-code response and leaves
the still-valid code unconsumed so it can be retried after the app finishes syncing.

Partial revocation removes one resource grant; connection revocation removes all
grants. Access is denied in the same transaction, a tombstone appears on the
next pull, and queued full-data webhooks are cancelled. Operators must erase the
revoked copy within seven days and call the idempotent acknowledgement endpoint.
The portal warns after five days and production clients are suspended at seven
days while the obligation is outstanding.

A fresh initial sync also includes every still-retained tombstone. This is
intentional: losing or resetting a cursor must never allow an operator to miss
a prior deletion obligation.

Rich integration copies are purged within 24 hours after their final grant.
Operational access/delivery logs and tombstones default to 90 days and minimized
consent evidence to three years. These configured periods remain a production
gate until legal approval is recorded.