Start here

If you have not signed in yet, the getting-started guide takes you from SSO to your first report in six steps. If you are already set up and want to instrument something, jump straight to the relevant guide below.

Everything on these pages is generated from the platform's own source rather than written from memory, so the endpoints, column names and configuration keys are the real ones. Where something is not supported, it says so plainly instead of leaving you to discover it.

The guides

Each one is complete and standalone, with working code rather than fragments.

How to Get Started

SSO sign-in, creating a tenant, connecting a ClickHouse server, sending your first event and building your first report. Six steps, each with a visible success signal and a troubleshooting section for when it does not work.

Track Websites

The browser SDK end to end: automatic page views and clicks, custom events, the full configuration reference, single-page app integration for React, Vue, Next and Angular, consent gating, and mapping your own dimensions onto existing markup.

Track Mobile Apps

There is no native SDK, deliberately. Complete Swift, Kotlin and React Native clients under 150 lines each, with disk-backed offline queueing, jittered backoff and lifecycle flushing.

Track Server-Side Apps

Node, Python, Java and shell clients that never let an analytics failure become a product failure. Includes backfilling history and how to make an import idempotent.

Your ClickHouse Server

A container for evaluation, a TLS-fronted Compose setup, a least-privilege user, retention, backups, health queries and materialised views for when a panel gets slow.

AEMaaCS Integration

Both halves of AEM: author-side asset, publish and login events through an OSGi bundle, and the published site through the browser SDK — with a complete bootstrap script, HTL fragment, Sling model and every OSGi configuration file.

The contract, in one place

Two endpoints matter. Ingest takes no credentials, because the tenant and site pair in the URL is the credential and the path is write-only. Reading reports does take a token, because that path can see your data.

API reference

The endpoints you will use directly. Everything else in the console is built on these.

Method & path Auth Body / params Returns
POST /il/analytics/{tenant_id}/{site_id}/events None — the URL pair is the credential One event object or an array, max 1000 201 {success, message, count}
POST /il/token companyId, tenantName, clientKey, clientSecret headers A JWT; its tokenId is what you send as x-il-token
POST /il/analytics/{t}/{s}/report-query Bearer session or x-il-token {query, runtimeFilters?, timeRangeOverride?, pagination?, timezone?} {success, data, columns, rowCount, totalCount}
GET /il/analytics/{t}/{s}/events Bearer or token start, end, event_type, user_id, page_url, limit, offset, order_by Raw event rows
GET /il/analytics/{t}/{s}/summary Bearer or token Count, first and last event per event_type
GET /il/analytics/{t}/{s}/report-dsl-metadata Bearer or token lookbackDays, refresh Dimensions and metrics, including custom keys found in your data
GET /il/analytics/{t}/{s}/field-values Bearer or token field, lookbackDays, limit Distinct values, for populating filter dropdowns
GET /il/analytics/{t}/{s}/realtime-users Bearer or token bucketSeconds, bucketCount, idField Live user counts per bucket

Everything, in four requests

If you read nothing else on this site, read this.

curl -sS -X POST \
  'https://api.infralytiqs.com/il/analytics/acme/acme-www/events' \
  -H 'Content-Type: application/json' \
  -d '{
        "event_type": "page_view",
        "page_url": "https://acme.com/pricing",
        "anonymous_id": "a7f3c1e0-9b2d-4c8a-8f11-2d6b5e4c9a13",
        "session_id": "s-2026-07-25-0914",
        "device_type": "desktop",
        "device_os": "macOS",
        "language_iso_code": "en-GB",
        "custom_dimensions": { "plan": "trial" },
        "custom_metrics": { "scroll_depth": 82 }
      }'

# 201 { "success": true, "message": "1 event(s) ingested successfully", "count": 1 }

How the pieces fit

Four hops from an interaction to a chart.

Sources

Websites

Browser SDK

/features/websites-analytics

Mobile

Plain HTTPS

/features/mobile-apps-analytics

Server-side

Batched REST

/features/server-side-analytics

AEM

OSGi bundle

/aemaacs-integration

Ingest

Collector

Tenant + site validated

403 if unknown

GeoIP

country_code

IP discarded

Store

Your ClickHouse

website_events

/docs/clickhouse

TTL

24 months default

Yours to change

Report

Query API

Report DSL to SQL

Column whitelist

Console

14 panel types

Or your own SQL

The only part we hold is the middle. Sources are yours, storage is yours, and the SQL access at the end is yours.

Reserved field names

Use these exact keys and the platform gives you something extra. Anything else is still perfectly valid — it just lives in the maps.

Key Where it goes Why it is special
event_type Its own LowCardinality column The primary grouping for nearly every report. Keep the cardinality low
event_subtype Its own column A second level without inflating event_type
search_term custom_dimensions, then MATERIALIZED Promoted into a real column, so grouping by it is free
asset_id custom_dimensions, then MATERIALIZED Same treatment. The join key between AEM author and publish events
page_url Its own column page_path is derived from it as an ALIAS, costing no storage
anonymous_id Its own column The usual basis for unique visitor counts
session_id Its own column Session counts, and the boundary for per-visit funnels
user_id Its own column How you stitch web, mobile and server-side activity together
country_code Its own column Overwritten by the collector's GeoIP lookup, so do not fight it
event_time Its own DateTime64(3) column Settable, which is what makes backfilling possible

Questions people ask before adopting

Sign in, create a tenant, run a ClickHouse container, connect it, and curl one event. That is realistically ten minutes, and every step has a visible success signal so you are never guessing. The getting-started guide is that path in order.
No. The console is a convenience over your own database. Ingest events, then query the table with any SQL client, or drive the report-query API from your own application. Plenty of teams use the collector and the schema and build their own front end.
The storage is self-hosted by default — that is the whole design. Running the collector and console inside your own network is possible too, but it is a paid engagement rather than a self-service option, so get in touch if you need it.
There is a browser SDK. Everything else is an HTTPS POST with a JSON body, so the guides give you complete clients for Swift, Kotlin, React Native, Node, Python, Java and shell — around 100 lines each, which is genuinely less work than adopting a dependency.
Worth knowing up front: there is no fixed report catalogue, since reports are tenant-defined; no dedicated funnel or retention panel type, though ClickHouse's own functions cover both; no attribution network; no session replay; and the AEM integration is asset-centric rather than tracking Sites pages or workflows.
The contact page. If the answer turns out to be missing from these guides rather than from the product, that is a documentation bug and worth reporting as one.

Start with the first step

Six steps from nothing to a working dashboard, with no card and no call.