Platform
Apolaki is planned as two products on one data layer: a warehouse-native CDP first, followed by a CRM that can work standalone and becomes stronger when paired with the CDP.
Apolaki is not yet commercially available. The roadmap describes intended sequencing, not current product availability.
Apolaki is in planning and validation. The first planned build cycle is the CDP foundation. CRM is planned only after the CDP foundation is solid.
Customer data platform planned for your warehouse.
Apolaki CDP is being designed to collect events from browser, server, and REST sources. The planned identity layer resolves anonymous and known activity into a single profile, then makes that profile available for warehouse-native activation. Profiles are intended to live in Snowflake or BigQuery, not in a proprietary Apolaki profile database.
The identity engine is planned around seven resolution cases: new anonymous visitors, anonymous-to-known stitching, known profile merges, trait updates, merge chains, and conflict resolution. Cross-tenant isolation is a required design constraint.
The planned connector tiers all produce the same event envelope and attach consent before events enter the pipeline.
Target: under 8KB with no dependencies. Planned capture includes pageviews, anonymous ID, session context, and consent state from OneTrust and GTM dataLayer.
Planned PHP, Python, and Node.js SDKs for purchase events, authentication events, server-side identify calls, and batch imports. Same event envelope as the browser SDK.
Planned REST API for systems that can make a POST request, including Zapier, CRM webhooks, legacy applications, and batch imports. Write key authentication and queue dispatch are part of the design.
The planned event path moves from collection to destination with consent checked at the points where data changes state or leaves the platform.
| # | Layer | What it does |
|---|---|---|
| 1 | Connector | JS SDK, server SDKs, and REST API. All planned to output the same event envelope |
| 2 | Ingestion | Validates events, authenticates write keys, attaches consent state, dispatches to queue |
| 3 | Pipeline | Enforces schema, enriches context, gates on consent, fans out to identity and destination queues |
| 4 | Identity engine | Resolves anonymous to known, merges profiles, updates trait store |
| 5 | Profile store | Postgres for live reads and writes, Snowflake for batch and warehouse queries |
| 6 | Activation | Audience builder, computed traits, destination sync, reverse ETL |
| 7 | Control plane | Dashboard for sources, destinations, live event debugger, profile viewer, and consent log |
Contact and pipeline management planned after CDP foundation.
Apolaki CRM is planned as a contact, account, deal, and pipeline layer that can work standalone. It is intentionally sequenced after the CDP foundation, not before it.
When paired with the CDP, each CRM contact is intended to connect to a full behavioral profile from the warehouse. The goal is to show page visits, event history, and audience membership alongside deal data in the same view.
Planned: contacts, accounts, deals, pipeline stages, activity log, and email integration.
Planned: full behavioral profile per contact, audience-driven views, and pipeline changes that trigger CDP events.
Apolaki is being planned for teams that want warehouse-native profiles, consent-aware activation, and a practical path from CDP to CRM.
| Capability | Planned Apolaki | Segment | RudderStack | Hightouch |
|---|---|---|---|---|
| Profiles in client's warehouse | ✓ | ✗ | Partial | ✓ |
| Consent on every event record | ✓ | ✗ | ✗ | ✗ |
| Flat workspace pricing | ✓ | MTU-based | Event-based | Row-based |
| Agency white-label | ✓ | ✗ | ✗ | ✗ |
| CRM included | ✓ | ✗ | ✗ | ✗ |
| Own event protocol | ✓ | Proprietary | Segment-compatible | n/a |
10 to 50 staff managing multiple client MarTech stacks. The cost per client on existing CDPs adds up fast. The planned model supports separate workspaces per client and an agency-friendly handoff.
Independent consultants and fractional CTOs who need a CDP they can eventually set up for a client in a week, not a quarter. The planned platform emphasizes a clean API surface and self-serve workspace provisioning.
FERPA-aware institutions with lean teams and budgets that do not support six-figure enterprise software. The planned data model treats consent as a first-class field from day one.
Organizations that need contact management first and an event pipeline later. The CRM is planned to work on its own, then become stronger when connected to the CDP.
Apolaki is pre-build. The roadmap below explains intended sequencing, not current product availability.
Architecture, event model, consent model, connector strategy, data schema, and early customer discovery.
Laravel API, 10-table schema, write key authentication, event ingestion, SQS dispatch, and consent-aware event envelope.
Anonymous-to-known stitching, profile merge rules, destination connectors, delivery audit logs, and live event debugging.
Contacts, accounts, deals, pipeline stages, activity log, and CDP-backed profile context when the CDP is enabled.
I am collecting feedback before the first build cycle. Share the CDP, consent, CRM, or activation problem you are trying to solve.
Apolaki is not yet commercially available.
Share your use case