Age band
Bucketed — never exact age. "13-17" through "65+".
Recognition without round-trips.
SMRT is BoxOwl's header injection protocol. The extension injects signed JWTs into requests to registered org domains — verified locally via JWKS, no callback to BoxOwl per request. Two tiers, one verification path.
The two tiers
One protocol, two tiers — additive.
Every PDaaS org is also a SMRT org. Pick the depth of integration your use case needs.
| Tier | Header | What orgs get | What it requires |
|---|---|---|---|
| 1 — SMRT | X-BoxOwl-Smrt |
Anonymized preference signals — age band, region, style, palette, interests — on every request from any BoxOwl user. | Register org + list domains. No API key. |
| 2 — PDaaS | X-BoxOwl-Identity |
Name, verified flag, pairwise orgUid, plus the SMRT profile. Optional data API for additional scopes. Optional org-stored tags claim for silent customer matching, plus live propagation webhooks and batch sync — all included. |
Org API key + user connection. |
Tier 2 detail on the PDaaS page. Everything below is the SMRT-tier substrate both share.
A request from a logged-in BoxOwl user arrives at your server
// HTTP request to a Tier 1 domain GET /welcome HTTP/1.1 Host: yoursite.com X-BoxOwl-Smrt: eyJhbGciOiJSUzI1NiIsImtpZCI6Ii4uLiJ9.eyJzdWIi... // Your server verifies the JWT via JWKS and reads the claims { "sub": "3f5c2d8e-7b13-4a91-9c47-1ab23456cdef", // rotating session UID "smrt": { "ageBand": "25-34", "region": "CO", "styleRoots": ["minimalist", "scandinavian"], "colorPalette": "earth-tones", "interests": ["outdoor", "cooking"] }, "iss": "boxowl.me", "iat": 1748390400, "exp": 1748391000 }
The SMRT profile
One profile. Every site. User-controlled.
The SMRT profile is org-agnostic — the same block ships in every JWT the user's extension emits, anywhere on the registered-domain list. No PII, no precise location, no fingerprintable specifics.
Region
State or country code. "CO", "US", "GB" — never precise location.
Style roots
Multi-select categories — minimalist, scandinavian, mid-century, industrial…
Color palette
Single pick — earth-tones, monochrome, jewel-tones, pastels, neon…
Interests
Opt-in categories — outdoor, cooking, music, books, fitness, design…
Every claim is optional
The user chooses which categories to populate. Empty fields drop out of the JWT — orgs see only what the user shares.
What SMRT is for
The moments where you just need a signal.
No checkout flow. No data sync. No consent dance. Just personalization.
Style-aware merchandising
Reorder the grid by style affinity. Surface minimalist-tagged SKUs to minimalist-preferring shoppers — without a login.
Palette-driven theming
Pre-select a theme variant. Earth-tones get warm accents, neon gets electric blue — set on the first request.
Smarter recommendations
Use interests as a cold-start signal for your existing recommender. No model, no API key — just signals.
BoxOwl-user counting
Distinguish BoxOwl users from anonymous visitors in your analytics. Session UID rotates every 10 minutes — no individual tracking.
Community badging
Conferences and community sites auto-badge BoxOwl users as they browse, with no separate registration.
Drop-in upgrade path
Start with SMRT. Add PDaaS when you need identity. Enable the tags claim on your PDaaS connection when you need silent matching. Same verification path, same protocol.
Two JWT shapes
Same signing key. Same verification path. Different audience.
The extension picks which header to inject based on whether the user has an active connection with the org.
X-BoxOwl-Smrt (Tier 1)
Injected on every registered org domain.
sub: rotating UUID session id (10-min lifetime)smrt: profile signals — ageBand, region, styleRoots, colorPalette, interestsiss:boxowl.me- RS256, 10-min TTL
- No identity — no name, no handle, no email, no stable UID
- Public — every BoxOwl user emits one
X-BoxOwl-Identity (Tier 2)
Injected only on connected-org domains.
sub: pairwiseorgUid— stable per (user, org), different for every orgname,verified,tierclaimssmrt: same profile block as Tier 1org: org slug — receivers reject if mismatchedtags(PDaaS, optional): org-stored customer annotations for silent matching- RS256, 30-min TTL
How it works
Two stores. One mint per session UID rotation.
The extension maintains a global registered-domain list and a per-user connection store — both ETag-conditional, both refreshed in the background.
Register the org and your domains
Tier 1 is zero-config — register your org, list your domains, done. The extension polls a global list of registered domains and refreshes every six hours (ETag-conditional). For Tier 2, add an API key and configure the consent flow.
The extension mints + injects
At login (and every 10 minutes), the extension calls POST /api/v1/smrt/session to mint the Tier 1 JWT, then installs a single declarativeNetRequest rule that injects X-BoxOwl-Smrt on every registered-domain request. Tier 2+ JWTs are minted on-demand via POST /api/v1/smrt/batch-mint when navigation lands on a connected-org domain.
Your server verifies locally
Fetch the JWKS from /.well-known/smrt-jwks.json, cache by kid, and verify each JWT locally. No callback to BoxOwl per request. Visitors without BoxOwl fall through to anonymous.
Privacy model
No identity by default. No correlation by design.
The Tier 1 JWT is anonymous. The Tier 2 JWT uses pairwise UIDs so two orgs can't link the same person.
No PII in the SMRT tier
Tier 1 JWTs carry no name, no handle, no email, no UID — just bucketed preference signals.
10-minute session UID rotation
The Tier 1 sub is a UUID that rotates every 10 minutes — caps cross-site behavioral tracking to that window.
Pairwise orgUid
Every (user, org) pair gets a unique orgUid. Two orgs cannot correlate their values to identify the same person.
User-controlled profile
Every SMRT field is opt-in, configured in the user's BoxOwl account. Empty categories drop out of the JWT entirely.
BoxOwl doesn't see your traffic
JWTs go straight from the user's browser to your server. BoxOwl mints and signs; the headers are point-to-point.
Registered-domain-only injection
The extension never injects on unregistered sites — BoxOwl presence is not revealed to arbitrary websites.
When you need more
SMRT is the substrate. PDaaS layers on identity, vault reads, propagation, and silent matching.
Same verification path, same protocol. You upgrade by registering API keys + handling consent — not by changing how you read headers.
Need vault data?
Use PDaaS. The user grants a connection scoped to specific fields (address, contact, work history). The identity JWT recognizes them; the data API delivers the rest.
See PDaaS →Need to match your own customer DB?
Enable the tags claim on your PDaaS connection. Store your customer-id as a tag on the connection; it ships back in every identity JWT. Silent match on the first request — no callback. Included in PDaaS, no separate tier.
Frequently asked
The questions teams ask first.
What's the SMRT profile?
An org-agnostic block of opt-in preference signals — age band, region, style roots, color palette, interests — that the user controls in their BoxOwl account. The same profile ships in every SMRT JWT the user emits, regardless of which site they're visiting.
Does my server need API keys for SMRT?
No. The SMRT tier (X-BoxOwl-Smrt) is JWKS-verified locally — there are no API keys on this path. The PDaaS tier uses org API keys for the optional data API, but identity-JWT verification still happens locally.
How are SMRT JWTs verified?
RS256 with a public key set published at /.well-known/smrt-jwks.json. Fetch the JWKS, cache by kid, and verify each token locally. No shared secret. No per-request callback.
What stops me from seeing both headers at once?
The extension installs a higher-priority rule for X-BoxOwl-Identity that also removes X-BoxOwl-Smrt. Connected-org domains see only the identity JWT — the protocol's mutual-exclusion rule.
Does SMRT work without the BoxOwl extension?
No. SMRT is a header-injection protocol; the extension is the injector. Visitors without the extension get no headers — graceful degradation by design.
Will my SMRT JWT carry on the very first navigation HTML request?
Tier 1 yes — the global injection rule installs at extension boot. Tier 2 has an MV3 constraint: X-BoxOwl-Identity is installed on demand at webNavigation.onCommitted, so the first HTML request to a connected org may not carry it. Every subsequent in-page request does. Org integrations that read identity on API calls (rather than the document request itself) are unaffected.
See it live
Both tiers running in a real storefront.
The BoxOwl Store demo (store.boxowl.me) is a working integration of both tiers — SMRT preference signals before sign-in, the full PDaaS Identity JWT (with silent matching via tags) after.
Sign-in to BoxOwl, configure your SMRT profile, install the extension, then visit the demo.
The hero, catalog ordering, and theme accent all shift based on your colorPalette and
styleRoots. Connect the store with PDaaS to see the recognized-user greeting.
Pick the tier that fits.
SMRT is in private beta. Request an organization token, or jump straight into the integration docs.
Not an organization? See features for individuals →