Opaque by design
A mask is random and non-semantic. It is not derived from your address, identity, ZIP code, or coordinates.
Store your verified US address once. Share a revocable mask instead. Authorized resolvers receive only the fields permitted for a specific purpose and time.
US early access · No address data collected on this pageTaylor Reed
Hidden by defaultAM-7Q4K-9M2P
Shareable identifier · not a bearer credentialMost services need an outcome: deliver this order, confirm this service area, calculate this jurisdiction. They do not all need the same address fields forever.
AddressMask separates the identifier you share from the temporary credential that authorizes a specific disclosure.
Five deliberate boundaries replace one uncontrolled copy-and-paste.
Authorized delivery resolver · ORDER-10482
The same protected address can answer different authorized questions without giving every caller the full record.
123 Example Street Austin, TX 78701
A single-use shipping token releases a verified delivery address to the intended resolver.
No additional fields returnedProtection status comes first. Address details stay behind deliberate actions while permissions and activity remain easy to understand.
Illustrative interface using synthetic data. Product behavior is in development.
AddressMask is designed around explicit policy boundaries—not the assumption that possessing an identifier should reveal a home address.
A mask is random and non-semantic. It is not derived from your address, identity, ZIP code, or coordinates.
The product architecture calls for address payloads to remain encrypted outside authorized resolution paths.
Every disclosure-capable token names a purpose, audience, explicit fields, and an expiry.
Missing or ambiguous authorization inputs are designed to return a denial, with no protected data.
Only an approved, authenticated resolver can request the fields permitted by policy.
Material decisions are designed to record the result and fields released without logging raw address data.
Trust boundary: architecture requirements are not a certification. Independent security assessment remains a production launch requirement.
Request a purpose-bound token, pass it to an approved resolver, and receive only the fields allowed for that transaction.
We're preparing the first US pilot. No email is being collected on this deployment.
POST /api/v1/masks/AM-7Q4K-9M2P/tokens
{
"purpose": "SHIPPING",
"audience": {
"type": "resolver",
"id": "rsv_04"
},
"shipment_ref": "ORDER-10482",
"requested_fields": [
"full_delivery_address"
],
"expires_in_seconds": 86400
}Illustrative contract. No live credentials or address data.
AddressMask adds a controlled disclosure layer. It does not make the surrounding delivery network disappear.
It is an opaque, shareable identifier mapped to a protected address vault. The identifier itself contains no address information and does not grant permission to reveal an address.
No. A mask is not a bearer credential. A disclosure requires a purpose-specific, audience-bound, field-scoped, expiring authorization and an approved resolver.
Not by default. A merchant or carrier must use a supported AddressMask integration and an authorized resolver. AddressMask does not replace USPS, UPS, FedEx, or other addressing standards.
No. A permitted request can return a smaller result such as service-area eligibility, tax jurisdiction, verification status, or postal code. Full delivery addresses require an authorized full-address flow.
The product model supports revocable masks, permissions, and unused access tokens. Full-address shipping tokens are designed to be single-use by default.
The first product scope is for verified United States addresses. International support and exact production availability are not yet being promised.
Join the list for product updates and opportunities to participate in the first controlled pilot.
We're preparing the first US pilot. No email is being collected on this deployment.