Everything Flockr exposes through native integrations is also available as primitives: webhooks for real-time events, GraphQL and REST APIs for on-demand queries, partitioned Parquet for bulk export. Build your own integration with anything that speaks HTTP. The capability surface is the same; only the destination changes.
Custom and developer integrations exist for everything Flockr's native connectors don't cover — tools the customer's team has built themselves, platforms not in the standard list, internal systems that need Flockr data alongside other inputs, or bespoke workflows that combine signal events with custom logic.
The capability is the same as the native integrations; what changes is that the customer's engineering team builds the destination rather than installing it. Three access patterns cover every case.
The framing is access shape — how your code gets data from Flockr. Three independent patterns that cover every custom integration. Pick the one that matches your use case.
Flockr fires webhooks to your endpoints when events happen. Cohort transitions, signal threshold crossings, configurable triggers. CloudEvents-shaped HTTP POSTs, HMAC-signed, with documented retry semantics. The right pattern for real-time custom integrations — Slack alerts, internal dashboards, bespoke message routing.
GraphQL and REST APIs for on-demand data retrieval. Cohort membership, signal state for a product, the full Flockr context for a visitor. The right pattern when your code needs Flockr data at a specific moment — page render, checkout decision, customer-service lookup.
Bulk Parquet export to object storage on a configurable schedule. Cohort membership tables, signal snapshots, event-level streams. The right pattern for analytical workloads, custom reverse-ETL pipelines, or feeding Flockr data into systems that prefer batch ingestion.
Each pattern is a standard interface — no proprietary protocols, no custom client libraries required. Implementation detail lives in the developer documentation; the panels below describe what to expect.
CloudEvents 1.0 envelope, JSON body with documented schema per event type. HMAC-SHA256 signature in a header for verification. Automatic retries on 5xx responses with exponential backoff. Idempotency keys for de-duplication.
GraphQL endpoint for typed queries with field selection. REST endpoints for simpler scripting use cases — both cover the same surface area. Bearer-token authentication, standard OAuth 2.0 client credentials flow for service-to-service auth.
Partitioned Parquet files written to S3 on a configurable schedule. Per-client buckets with cross-account access via assume-role. Snappy-compressed, partitioned by date for efficient pruning. Schema versioned and additive — new fields appear without breaking existing readers.
Full schema documentation, endpoint references, example payloads, and SDK availability are in the developer documentation. The page above describes the integration shape; the docs cover the specifics.
Read the developer documentation →
Custom integrations don't have named platforms — they have use cases. Six examples of what customers have built or could build with the three primitives above.
Slack and Teams bots that fire on cohort entries, surfacing high-value cart abandoners and at-risk customers to the CX team in real time. The most common custom integration — built once, runs forever.
Native iOS and Android apps consuming Flockr's API for product-state context — scarcity, momentum, lifecycle stage — to render demand-aware content in app surfaces. Valuable for retailers whose native app team operates independently.
Custom data-engineering pipelines reading Flockr's Parquet exports and pushing to destinations Hightouch and Census don't cover — legacy systems, regional ad platforms, internal data products. The customer's data team owns the pipeline.
Internal-facing dashboards consuming Flockr's webhook stream for live cohort-entry visibility. Trading-desk-style displays showing demand state across the catalogue, alerting on threshold crossings, supporting merchandising decisions in real time.
Custom decisioning code calling Flockr's GraphQL API at page render time to fetch the visitor's current cohort context, then choosing content, recommendations, or offers based on logic the customer's team owns. The right pattern when off-the-shelf tools fall short.
One-off integrations with platforms not in Flockr's native list — bespoke POS systems, legacy email tools, regional commerce platforms, proprietary loyalty engines. Same webhook-and-API pattern as Flockr's native integrations, implemented by the customer's team.
Building something not listed here? The capability surface is documented; what customers build with it is up to them.Get in touch if you want to discuss the integration shape before starting →
A retailer wants their CX team to see real-time alerts in Slack whenever a high-value cart abandonment happens, so they can reach out personally to recover the order. They build a small webhook handler that subscribes to Flockr's high_value_cart_abandoner cohort and posts to a Slack channel.
The webhook contract, signing semantics, and event schema are documented; the customer's team owns the handler, the identity resolution, and the destination logic. Flockr's responsibility ends at the webhook delivery.
In the Flockr portal, register a webhook destination pointing to the customer's handler URL. Subscribe to the cohort.entered event type, filtered to the high_value_cart_abandoner cohort. Copy the per-endpoint signing secret to the handler's environment.
The handler receives Flockr's POST. Verify the HMAC signature against the configured secret. Reject if it doesn't match. Parse the JSON body — CloudEvents envelope, with cohort entry details in data.
The handler reads the event properties: cart_total_value, cart_product_ids, flockr_vid. It looks up the visitor's customer record (via the customer's own identity table; see the note below) to get a name and email if available, then builds a Slack message with cart details and a link to the customer admin page.
The handler posts to the configured Slack incoming webhook URL. The CX team sees the alert within seconds of cohort entry. They click through to the admin, review the cart, and reach out to the customer directly.
The webhook contract, signing semantics, and event schema are documented. The customer's team owns the handler, the identity resolution, and the destination logic. Flockr's responsibility ends at the webhook delivery — what happens next is custom code in the customer's environment.
Flockr's primitives identify visitors by flockr_vid — an anonymous browser-scope identifier. For custom integrations that need to map Flockr signals to identified customers (email, phone, account ID), the resolution happens on the customer side. Most teams maintain a small identity table populated when their tag captures the resolution event — login, signup, checkout, email click — and joined at the moment the custom integration needs it.
The same applies in reverse. Custom integrations that need to push customer-identified data back into Flockr should pass identifiers the customer holds (external_id is a standard field on Flockr's APIs for this), keeping Flockr's analytics pipeline free of PII. The two-tier privacy posture from the integrations hub page applies — Flockr's pipeline stays PII-free, the custom integration handles identity resolution in the customer's environment under a DPA scoped to the integration shape.
The developer documentation covers schemas, endpoint references, example payloads, and SDK availability. If you want to discuss the integration shape before starting, get in touch.
