Operations: data fabric
Bricqs is built around a small set of standard fields, deliberate PII handling, and per-tenant access controls. This page covers what data lives where, how PII is masked, how GDPR exports and erasure work, and how to wire outbound data flows safely.
Key takeaways
Quick read- Eleven standard fields cover the canonical PII surface: email, name parts, mobile, country code, DOB, gender, city, postal code, external_id.
- Masking is policy-based and enforced server-side on read. Clients cannot bypass it.
- Every PII read produces an audit log row. Required for GDPR and SOC 2.
- GDPR erasure nullifies fields; it does not delete events. Audit trails stay intact.
- Outbound webhooks support per-event redaction so PII never leaves your tenant unintentionally.
Standard fields
The canonical PII surface
Every participant has these fields. Profile-enrichment routines auto-coalesce values from form submissions, surveys, and explicit upserts.
Standard fields (canonical IDs):
email
first_name
last_name
full_name
mobile_number
country_code
date_of_birth
gender
city
postal_code
external_id
Custom fields:
Anything else (preference flags, behavioural attributes).
Marked PII at field-definition time if applicable.Masking
What clients see by default
| Field | Default mask | Full read requires |
|---|---|---|
| a***@domain.com | scope: read:pii | |
| mobile_number | Last 4 digits | scope: read:pii |
| first_name / last_name | First 2 chars + *** | scope: read:pii |
| full_name | Initials only | scope: read:pii |
| date_of_birth | Year only | scope: read:pii |
| city / postal_code | Visible | (no extra scope) |
| external_id | Visible | (no extra scope) |
Audit log
Every PII access is logged
pii_access_log row format:
id UUID
tenant_id UUID
actor_type "admin" | "system" | "webhook"
actor_id admin user id, system component, or webhook subscription id
participant_id whose PII was read
fields_accessed JSON array of canonical field names
row_count 1 (single read) or N (bulk export)
export_format "json" | "csv" | null
ip_address INET
occurred_at timestamptz
Queryable via /admin/audit/pii-access. Required for GDPR and SOC 2 audits.
Retain for at least 12 months by default; longer per your DPA.GDPR export
Article 15 (right of access)
curl -X POST https://api.bricqs.co/api/v1/admin/participants/p_8a3f/export \
-H "Authorization: Bearer bq_live_admin_..." \
-H "X-Bricqs-Tenant: tenant_brand_xyz" \
-d '{ "format": "json", "include": ["profile", "events", "rewards", "challenges"] }'
# response (signed URL valid for 24h)
{
"export_id": "exp_91xx",
"ready_at": "2026-04-30T12:14:00Z",
"url": "https://exports.bricqs.co/...",
"size_bytes": 48211
}Exports are async. Most complete inside 5 minutes. The signed URL expires in 24 hours; download once and store on your side.
GDPR erasure
Article 17 (right to be forgotten)
curl -X POST https://api.bricqs.co/api/v1/admin/participants/p_8a3f/erase \
-H "Authorization: Bearer bq_live_admin_..." \
-d '{
"fields": "all_pii",
"anonymize_session_ids": true,
"reason": "user_request_2026_04_30"
}'
# response
{
"erased_at": "2026-04-30T12:18:00Z",
"fields_nullified": ["email", "first_name", "last_name", "full_name",
"mobile_number", "date_of_birth"],
"events_anonymized": 1247,
"audit_log_id": "log_91xx"
}Erasure nullifies fields; it does not delete events or facts. Aggregate analytics and contest leaderboards remain intact (the participant becomes 'deleted user'). Required pattern for most jurisdictions.
Outbound
Webhooks and exports with redaction
{
"url": "https://api.your-app.com/bricqs/webhooks",
"events": ["challenge.completed", "reward.issued"],
"redact": ["email", "mobile_number", "date_of_birth"]
}
# Outbound payload then includes:
{
"data": {
"participant_id": "p_8a3f",
"email": "[REDACTED]",
"mobile_number": "[REDACTED]",
...
}
}Use redaction when the receiving system does not need full PII (e.g. a Slack notifier). The participant_id is enough to look up the user in your authoritative store.
CDP and warehouse
Sync to your data layer
Outbound webhooks
Real-time. HMAC-signed. Best for triggering CRM and ESP workflows.
Scheduled exports
Hourly or daily JSON/CSV to S3 or GCS. Best for warehouse loads (Snowflake, BigQuery).
Reverse ETL
Sync curated audiences from your warehouse back into Bricqs as participant attributes. Connectors planned for Phase 4.
Direct read API
GET /admin/participants/search and /events/search. Best for ad hoc queries; rate-limited and not intended for bulk loads.
Common mistakes
What goes wrong
Granting read:pii to all admin keys. Audit logs balloon; insider risk grows.
Issue read:pii only to keys that actually need it (CSV export tools, support consoles). Most ops scripts can run on masked data.
Treating erasure as a delete. Aggregate metrics break.
Erasure nullifies PII fields; it does not remove events. Contest history and leaderboards stay intact under 'deleted user'.
Sending full PII over webhooks to systems that do not need it.
Use the redact field on the subscription. The receiving system gets participant_id and reads its own data store if it needs more.
Ignoring the audit log retention requirement.
Archive pii_access_log to your warehouse for the term required by your DPA. The Bricqs default retention is 12 months; longer needs explicit configuration.
Developer FAQ
Common questions when integrating gamification with Bricqs.
Ready to ship?
Wire it up with the Bricqs SDK or API
Headless SDK for React UIs, REST API for any backend. Same engine behind both.