AgeBridge · app age assurance
One age-compliance layer for every platform.
Apple, Google, Amazon, Texas, Utah, COPPA — the requirements are fragmented and moving. AgeBridge consumes the signals those systems produce and converts them into one consistent, auditable application decision. It does not replace platform age verification; it makes the results usable.
Input
- Platform
- Android
- Age category (from Play)
- 13–15
- Consent status (from Play)
- Not obtained
- Event
- Purchase in the app
- Jurisdiction
- Texas
Age is a range, never a birth date. We do not want one.
Decision
BLOCK
The app store reports no consent for this minor. Texas prohibits enforcing a contract or terms against a minor who agreed without it, so the purchase does not proceed.
- Platform source
- Play age signals
- Legal source
- Tex. B&C 121.056(a)(1)
- Rule
- SN-AGE-TX-005 v1
- Receipt
- SN-RCP-…
Illustrative example. Note the developer never obtains consent — the app store does, under §121.022. The developer verifies whether it happened.
One decision API
POST the platform, feature, jurisdiction, and normalized signals; get back ALLOW, BLOCK, or PARENT APPROVAL REQUIRED with rule IDs, versions, and a receipt.
Platform adapters
Apple's declared age range, Google Play's age signals, Amazon — each native signal is normalized into one vocabulary so your app logic stays platform-independent.
State laws, tracked
Texas and Utah app-store accountability acts, COPPA, and platform policy — normalized rules with sources, effective dates, and version history.
Privacy-first by design
Age ranges, never birth dates. No child names, no government IDs. The server receives the minimum needed to decide — data minimization is the architecture.
Significant-change reviews
Describe a feature you're about to ship; see per-platform whether it triggers parent notification, renewed approval, or new disclosures — before launch, not after.
Audit receipts
Every evaluation is sealed in a signed, hash-chained receipt tied to exact rule versions. When rules change, history stays intact.
The API, in one glance
POST /api/v1/age/evaluate
{ "platform": "ANDROID", "jurisdictions": ["US","US-TX"],
"feature": { "key": "in_app_purchase", "capabilities": ["PURCHASE"] },
"ageSignal": "13_15", "parentApprovalState": "NOT_REQUESTED" }
→ { "decision": "BLOCK",
"reason": "Driving rule: SN-AGE-TX-005 v1 — Texas prohibits enforcing terms
against a minor who agreed without consent. The store reports
consent not obtained.",
"rules": [{ "ruleId": "SN-AGE-TX-005", "version": 1 }, …],
"receiptId": "SN-RCP-…" }The consent events in Texas are exhaustive: download, purchase of an app, a purchase in an app, and re-consent after a significant change. A feature such as messaging is not one of them — it matters only if adding it is a significant change.