Solutions · Data & Engineering
No black boxes and no lock-in on your customer data. Sfere is an API-first platform that composes with your warehouse: connectors, a self-managed warehouse, SDKs and a complete API CLI, running on-premise or in your own cloud account, governed at the source
$ sfere apply -f pipeline.yaml
✓ schema ticket.scan v12 · 3 match rules compiled
✓ routes: wh_main, crm · delivery at-least-once
config v47 applied · your cloud · your region
$ sfere inspect profile P-101
identifiers: email + loyalty_no · events: 4 · consent: granted
$
apply · diff · inspect · rollback: the CLI mirrors the full API surface, so every change is reviewable in a pull request
How an event moves through the platform
One backend handles the full event lifecycle, and every stage is inspectable rather than a step you take on faith. Ten taped events ride the line below: two are malformed, most are duplicates. Press run, then open any station, and the line holds while you read the rules it executes
run · pause · step · inspect
line held · press run
station held open · the line pauses while you read the rules
Events land through connectors, get normalized by a transform, and are checked against a schema before anything is stored. Malformed payloads bounce out with the exact field that failed. Watch the reject tray under gate 01 while the line runs
schema ticket.scan · v12
required: [event_id, user_id, occurred_at]
fields:
user_id: string # null → reject
occurred_at: rfc3339
on_error: reject · field-level detailstation held open · the line pauses while you read the rules
Identifiers you define merge events into profiles by rules you control, with priorities that decide contested merges. No model, no probability score: duplicates collapse into the profile your rules select, in the open, and every merge is logged
match_rules: # deterministic
- { id: r1, key: email, priority: 100 }
- { id: r2, key: device_id, priority: 60 }
- { id: r3, key: loyalty_no, priority: 40 }
merge_limit: 5
conflict: highest_priority_wins
audit: every merge loggedstation held open · the line pauses while you read the rules
Warehouse tables map to the same identity graph, so batch history and live signal share one model. Historical data joins in-place, with no copy and no extra ETL hop, and profiles pick up a + hist tag as they pass gate 03
tables:
orders: { join: user_id, as: order_history }
loyalty_members: { join: loyalty_no, as: loyalty_state }
mode: in_place # zero-copy · no extra ETL hopstation held open · the line pauses while you read the rules
Enabled pipelines forward events to destinations you control, with delivery history and queue health queryable end to end Toggle every destination off above and events queue visibly instead of vanishing. Re-enable one and the queue drains
destinations:
- { id: wh_main, type: warehouse, status: enabled }
- { id: crm, type: http, status: enabled, retry: backoff(3) }
- { id: ads, type: http, status: paused }
delivery: at_least_once · history queryable
queue: visible · drainableWhat data teams get from Sfere
The capabilities other teams consume as products are exposed to you as an API, a CLI, and infrastructure you own
A connector framework normalizes web, app, streaming, and back-office events against typed schemas, so malformed payloads get rejected with field-level detail instead of poisoning the warehouse
POST /v1/eventstyped schema · 422 with error.fields[]Rule-based matching stitches events, warehouse rows, and profiles on identifiers you define, with priority and merge limits you set, not a black-box model you can't audit
match_rules[].prioritymerge_limit: 5 · every merge loggedMap tables in your columnar analytical warehouse to the same identity graph that handles live events. Historical data joins in-place, without a copy or an extra ETL hop
JOIN orders ON user_idcopy: 0 · etl_hops: 0Every capability sits behind a REST API and SDKs, and a CLI mirrors the full API surface, so configuration is reviewable, versionable, and works with CI/CD
$ sfere apply -f pipeline.yamldiff → pull request → CIConsent, access, and residency are enforced where the data lives, and every config object carries version history and soft delete, so a bad change is reverted, not mourned
config v14 · soft_delete: trueconsent · access · residencyRun on-premise or in your own cloud account, in the region you choose, on your keys and your infrastructure, with no data egress you didn't authorize
deploy: on-prem | your cloudregion: yours · keys: yours · egress: authorized onlyYour infrastructure, your rules
Sfere runs where you do. Consent, residency, and access are enforced at the data layer rather than bolted on after activation, and because configuration lives behind an API and a CLI, your pipeline is reviewable in a pull request instead of a vendor console
typical cdp
Their cloud
sfere
Your deployment
Walk the API surface, the deployment model, and the identity-resolution rules with our team, and pressure-test where your customer data actually lives