*expects stringified json value* | Default context object that will be merged with the `context` of every event. | | `cookieNames` | `data-cookie-names`
*expects stringified json value* | Map of alternative names for standard cookies. Format: `{"anonymousId":"my_eventn_id"}`
Default values:
`anonymousId`: `__eventn_id`
`userId`: `__eventn_uid`
`userTraits`: `__eventn_id_usr`
`groupId`: `__group_id`
`groupTraits`: `__group_traits` | | `cookieCapture` | `data-cookie-capture`
*expects stringified json value* | Map of cookies to capture in addition to Facebook's `_fbc`,`_fbp` and Google's `_ga` ids. Format: `{"id":"cookie-name"}`. Captured cookies will be added to `context.clientIds` object of event payload. | ### Privacy Settings :::info Available since Jitsu v2.8.0 and npm packages v1.9.7 ::: Privacy settings are nested under `privacy` object of Jitsu Options: ```javascript const analytics = jitsuAnalytics({ host: "https://your-jitsu-domain.com", privacy: { dontSend: false, disableUserIds: true, ipPolicy: "stripLastOctet", consentCategories: { "Analytics": true, "Marketing": false } } }); ``` | Name | Script Attribute | Description | |---------------------|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | `dontSend` | `data-privacy-dont-send` | If `true`, disables storing anything in cookies and sending events to Jitsu servers. | | `disableUserIds` | `data-privacy-user-ids` | If `true`, disables storing in cookies and sending to Jitsu servers any user identifiers (including anonymousId). In this mode `identify` and `group` calls will have no effect. | | `ipPolicy` | `data-privacy-ip-policy` | Controls how Jitsu collects information about user's IP: `keep` - collect full IP, `stripLastOctet` - collect only first 3 octets, e.g: `104.154.19.0` , `remove` - do not collect user's IP | | `consentCategories` | - | Object containing user's consent state by category name. Provided value will be passed to Jitsu in every event in `context.categoryPreferences` object. | ## Methods ### `.page()` Trigger page view. ```javascript //trigger page view with a custom name jitsu.page("Page Name"); //trigger page view with a custom properties jitsu.page({ propName: "propVal" }); //trigger page view with a name AND custom properties jitsu.page("Page Name", { propName: "propVal" }); ``` :::tip For [HTML Snippet](/docs/sending-data/html) page view is triggered automatically, unless `data-init-only` attribute is set to `true`. ::: ### `.identify()` Identify a user. ```javascript // Identify user: `xyz` as a userId, and additional properties (traits) jitsu.identify('xyz', { name: 'Michael Scott', company: 'Dunder Mifflin', }) //or just set a userId jitsu.identify('xyz') ``` `$doNotSend` is a special property that tells Jitsu to save user and it's properties to local storage, but not to send it to the server. This is useful to avoid sending excessive volumes of events to Jitsu ```javascript jitsu.identify('xyz', { name: 'Michael Scott', company: 'Dunder Mifflin', $doNotSend: true }) ``` :::tip Use `.identify()` for permanent user identifiers such as a database id of registered user. Use `.setAnonymousId()` for temporary identifiers such as cookies ::: ### `.track()` Send a custom event. ```javascript // Event name only jitsu.track("buttonClick"); // Event with properties jitsu.track("itemPurchased", { price: 99 }); ``` ### `.group()` Assign user to a group, usually a company or organization. ```javascript // Group ID. Use permanent identifiers such as a database id of company jitsu.group("g-xyz"); //Group with properties jitsu.group("g-xyz", { name: "Dunder Mifflin" }); ``` ### `.setAnonymousId()` Jitsu automatically detects anonymous id for each visitor. You can override it with `.setAnonymousId()` ```javascript //Set anonymous id of a user, such as ID of the visitor based on cookie jitsu.setAnonymousId("xyz"); ``` :::warning Jitsu automatically detects anonymous id for each visitor, you rarely need to use `.setAnonymousId()`. Use at your own risk. ::: ### `.setContextProperty()` :::info Available since Jitsu v2.11.0 and npm packages v1.10.1 ::: Allows to set a `context` property that will be sent with every event. Effectively, it sets property of `defaultPayloadContext` object that Jitsu merges with a standard `context` for every event. ```javascript jitsu.setContextProperty("pageViewId", "12345"); ``` ### `.getContextProperty()` :::info Available since Jitsu v2.11.0 and npm packages v1.10.1 ::: Get a property of `defaultPayloadContext` object if available. ```javascript const pageViewId = jitsu.getContextProperty("pageViewId"); ``` ### `.configure()` :::info Available since Jitsu v2.8.0 and npm packages v1.9.7 ::: Change Jitsu configuration on the fly. Only `privacy`, `debug` and `echoEvents` settings can be changed on the fly. ```javascript //Change Jitsu configuration on the fly jitsu.configure({ debug: true, privacy: { dontSend: true, disableUserIds: true, ipPolicy: "stripLastOctet" } }); ``` ### `.getConfiguration()` :::info Available since Jitsu v2.11.0 and npm packages v1.10.3 ::: Return current Jitsu configuration. --- Source: https://jitsu.com/docs/sending-data/js-reference/itp # ITP Mitigation :::info Available since Jitsu v2.8.0 and npm packages v1.9.7 ::: ## Safari Intelligent Tracking Prevention Intelligent Tracking Prevention (ITP) is an automatic feature of the Safari web browser designed to limit user tracking. ITP employs multiple measures to achieve this, one of which is the limited lifespan of first-party cookies :::info In Safari browser first-party cookies will be deleted after 7 days without access. ::: Since Jitsu relies on first-party cookies to store anonymous user IDs, ITP may negatively affect the quality of data collected by Jitsu. For example, if some user returns to a particular site after a pause of longer than 7 days, he will receive a new anonymous ID and may appear as a new user (at least unless `identify` is call is used). ## Mitigation Not all first-party cookies are subject to the ITP's 7-day expiry limit. Cookies with the `HttpOnly` flag, served directly from the customer’s website server, will not be removed by ITP. To enable ITP mitigation, customers need to add a simple service (endpoint) to their website that adheres to Jitsu’s specifications. ### Server setup Jitsu ID endpoint must be added to customer's website. #### Endpoint requirements: 1. ID endpoint must respond on the same domain as the website. (That can be a subdomain only if it resolves to the same IP address as the main domain) 2. Respond to `GET` HTTP method. 3. Read **domain** parameter from request query string. 4. Read `__eventn_id` or `__eventn_id_srvr` HTTP request cookie as a source of **anonymousId** value 5. If it couldn't acquire value for **anonymousId** from either of these cookies, generate a new one (UUID string) 6. Add `__eventn_id` and `__eventn_id_srvr` cookies to "Set-Cookie" headers with the following parameters:
`Set-Cookie: __eventn_id=anonymousId; Domain=domain; Max-Age=157680000; Path=/; SameSite=None; Secure;`
`Set-Cookie: __eventn_id_srvr=anonymousId; Domain=domain; Max-Age=157680000; Path=/; SameSite=None; Secure; httpOnly=true;`
where **domain** was acquired from query string and **anonymousId** was set previously 7. Send response with status `200` and JSON payload: `{ "anonymousId": anonymousId }` #### Optional part: It is also possible to protect the userId cookie from expiration, but a better approach is to `identify` the user on every new session. 8. Read `__eventn_uid` or `__eventn_uid_srvr` HTTP request cookie as a source of **userId** value 9. If it couldn't acquire value for **userId** skip the rest and do nothing 10. Add `__eventn_uid` and `__eventn_uid_srvr` cookies to "Set-Cookie" headers with the following parameters:
`Set-Cookie: __eventn_uid=userId; Domain=domain; Max-Age=157680000; Path=/; SameSite=None; Secure;`
`Set-Cookie: __eventn_uid=userId_srvr; Domain=domain; Max-Age=157680000; Path=/; SameSite=None; Secure; httpOnly=true;`
where **domain** was acquired from query string and **userId** was set previously 11. Change response with status `200` and JSON payload: `{ "anonymousId": anonymousId, "userId": userId }` ### Client setup Jitsu client library must be configured to use ID endpoint with `idEndpoint` parameter:
window.jitsuConfig object before inserting the snippet. Properties
of the object be same as data attributes, but camel cased and without data- prefix:
```html
```
### Google Tag Manager
Google Tag Manager [strips `data-` attributes](https://support.google.com/tagmanager/thread/18040523/what-attributes-are-preserved-on-custom-html-tags-and-what-attributes-are-stripped?hl=en) from the script tag. To configure Jitsu in GTM, you can use
following snippet:
```html
```
### `onload` hook
You can specify a piece of code that will be executed after the script has loaded. This can be useful if you
want to send additional events or identify user. Example:
```html
```
### Jitsu Processing Queue
Sometimes you may want to send events to Jitsu when it's not guaranteed that Jitsu is initialized. For that case,
you can use `window.jitsuQ` object:
```javascript
(window.jitsuQ = window.jitsuQ || []).push(function(jitsu) {
//send events to Jitsu here
jitsu.page();
});
```
## Sending Events to Jitsu
`window.jitsu` object implements standard [Analytics.js](https://getanalytics.io/api/) interface. See a full list of methods in [JavaScript Reference](/docs/sending-data/js-reference) section
---
Source: https://jitsu.com/docs/sending-data/http
# HTTP API
You can use HTTP API to send data to Jitsu.
This is useful if you want to send data from your backend.
:::tip
In all examples below, replace `your-jitsu-domain.com` with your Jitsu installation domain, or domain linked to your Jitsu Cloud account.
Jitsu Cloud users may find domain in the top-right corner of Site's **Setup Instruction** page or
attach custom domain for a specific Site and use it instead.
:::
## Authorization
### Write Key authentication
Use `X-Write-Key` header to authenticate requests. The header should contain the write key of the site.
### Basic authentication
Jitsu also supports basic authentication in the form of a base64 encoded `username:password` string.
Where **Write Key** must be provided as the `username` and the `password` field is left empty. E.g.: `writeKey123:` - despite empty password, the colon `:` is still required.
After base64 encoding `writeKey123:` becomes `d3JpdGVLZXkxMjM6Cg==` and this is passed in the authorization header like so: `Authorization: Basic d3JpdGVLZXkxMjM6Cg==`.
### Query parameter
You can also pass the `writekey` as a query parameter. This is useful for testing purposes, but not recommended for production use.
`https://your-jitsu-domain.com/api/s/{event-type}?writekey=keyId:keySecret`
## Ingest endpoint
This endpoint can be used to send events to Jitsu:
`https://your-jitsu-domain.com/api/s/{event-type}`
Can be used both for browser and server-to-server events depending on Write Key type.
**event-type** could be:
* `page`, `track`, `identify` or `group`
* Use `event` as `event_type` if you want server to take actual event type from `type` field of the event payload
The endpoint accepts POST requests with events payload in JSON format.
### Examples
`path.to.node` | path to node where write the value | | `process_headers` | Boolean. Enrich event with user and page data from HTTP headers: `Referer` and `Cookies` | | `cookie_domain` | When `process_headers=true` set Jitsu Anonymous Id cookie (`__eventn_id`) for provided domain | ### Examples Pass base64 encoded JSON payload to image pixel: ```html
HTTPS port (
8443 by default ) should be open in your ClickHouse server.
:::
**Warehouse type:**
```typescript
interface Warehouse {
query: (sql: string, params?: Record**the last in the pipeline**. If function that is not the last one in the pipeline returns array with more than one object – processing will be aborted with error and no events will be passed to the destination. ::: Example: create separate event for each product in purchase: ```javascript export default async function(event, { log, fetch }) { if (event.event == "purchase" && event.properties?.products?.length > 0) { let results = [] for (const product of event.properties.products) { results.push({ event_type: "purchase", product_id: product.id, price: product.price }) } return results } else { //skip events without any purchase return "drop" } } ``` ## SQL column type override To set specific SQL column type for the field, you can use `__sql_type_
Details
- Write to tmp file - Deduplicate rows in tmp file - Use Loader API to load to tmp_table from tmp file - `MERGE into target_table T using tmp_table TMP on T.pk_field=TMP.pk_field when matched then UPDATE ... when not matched them INSERT ...`Details
```sql -- Jitsu collects events batches in tmp file on file system. INSERT INTO tmp_table (...) VALUES (...); -- bulk load data from tmp file into tmp_table using prepared statement in transaction INSERT INTO target_table(...) SELECT ... FROM tmp_table ```Algorithm
```sql -- Jitsu collects events batches in tmp file on file system. ATTACH ':memory:' as jitsu_memdb INSERT into jitsu_memdb.tmp_table INSERT into target_table select from jitsu_memdb.tmp_table ```Algorithm
```sql -- Jitsu collects events batches in tmp file on file system. -- Deduplicate rows in tmp file ATTACH ':memory:' as jitsu_memdb INSERT into jitsu_memdb.tmp_table INSERT OR REPLACE into target_table select from jitsu_memdb.tmp_table ```Algorithm
```sql -- Jitsu collects events batches in tmp file on file system. BEGIN -- start transaction INSERT into tmp_table -- load tmp file into tmp_table INSERT into target_table select from tmp_table COMMIT -- commit transaction ```Algorithm
```sql -- Jitsu collects events batches in tmp file on file system. -- Deduplicate rows in tmp file BEGIN -- start transaction INSERT into tmp_table ... ON DUPLICATE KEY UPDATE ... -- load tmp file into tmp_table INSERT into target_table select from tmp_table ... ON DUPLICATE KEY UPDATE ... COMMIT -- commit transaction ```Algorithm
```sql -- Jitsu collects events batches in tmp file on file system. BEGIN -- start transaction COPY from STDIN to tmp_table -- load tmp file into tmp_table INSERT into target_table select from tmp_table COMMIT -- commit transaction ```Algorithm
```sql -- Jitsu collects events batches in tmp file on file system. -- Deduplicate rows in tmp file BEGIN -- start transaction COPY from STDIN to tmp_table -- load tmp file into tmp_table INSERT into target_table select from tmp_table ON CONFLICT UPDATE ... COMMIT -- commit transaction ````${AccountId}` with your AWS Account ID :::
`${WorkgroupARN}` with the Workgroup ARN value from your Redshift Serverless workgroup page :::
`${RoleName}` with your the name of role you [created](#create-a-new-iam-role) ::: ## Advanced: Implementation Details ### Batch Mode S3 is used as a intermediate storage for batched events.
Algorithm
```sql -- Write to tmp file -- Load tmp file to s3 BEGIN -- start transaction COPY from s3 to tmp_table INSERT into target_table select from tmp_table COMMIT -- commit transaction ```Algorithm
```sql -- Write to tmp file -- Deduplicate rows in tmp file -- Load tmp file to s3 BEGIN -- start transaction COPY from s3 to tmp_table DELETE from target_table T using tmp_table TMP where T.pk_field = TMP.pk_field INSERT into target_table select from tmp_table COMMIT -- commit transaction ```Algorithm
```sql -- Write to tmp file -- Load tmp file to user stage BEGIN -- start transaction COPY from stage to tmp_table INSERT into target_table select from tmp_table COMMIT -- commit transaction ```Algorithm
```sql -- Write to tmp file -- Deduplicate rows in tmp file -- Load tmp file to user stage BEGIN -- start transaction COPY from stage to tmp_table MERGE into target_table using (select from tmp_table) ... COMMIT -- commit transaction ```Profile Builder function should be located in the `src/profiles` directory and configured with the `profileBuilderId` config property within the function code.
Id of Profile Builder can be obtained from the `Settings` tab. ```typescript import { ProfileFunction } from "@jitsu/protocols/profile"; export const config = { profileBuilderId: "[Profile Builder ID]", // Required: id of Profile Builder where this function will be used. Can be found in the Profile Builder Settings UI slug: "profile.ts", //id (uniq per workspace) used to identify function in Jitsu }; const profileExample: ProfileFunction = async (events, user, { log }) => { //TODO } ``` ### Transformation Transformation allows you to filter or transform events before they are used for building a profile. In the Transformation section you can set up the chain of standard Jitsu [functions](/docs/functions) to process events before they are passed to the Profile Builder function. Use `return "drop"` to exclude an event from profile building. #### Custom Profile ID Using transformation, you can assign a profile ID to events that originally lacked a `userId` field or had a different `userId` field. To assign a profile ID to an event, add `JITSU_PROFILE_ID` property to the returned event object: ```javascript export default async function transform(event, { log, props, store }) { event.JITSU_PROFILE_ID = event.propeties.internalId; return event; } ``` ## Publishing Profile Builder Collecting of customers events history and profile-building logic starts after the initial version of Profile Builder is published. To publish the Profile Builder, click the `Publish` button in the top right corner of the Profile Builder editor. :::tip You can continue to work on your profile generation function after the initial version is published by utilizing the **Drafts**. Saved Drafts can be used for debugging and previewing profile results based on example events data and don't affect the production profile generation process. ::: Each time you publish a new version of the Profile Builder, the following happens: 1. Profile Builder's numeric `version` is incremented. 2. Profile Builder starts rebuilding profiles of all tracked customers based on the new version of the profile generation function.
This process may take some time depending on the number of customers and events and can be monitored on the `Build Progress` tab. 3. After the rebuild is complete, the new version of the profile generation function is used to rebuild profiles in real-time based on new events coming. --- Source: https://jitsu.com/docs/features/provisioned-warehouse # Provisioned ClickHouse [Jitsu.Cloud](https://use.jitsu.com) comes with preconfigured ClickHouse data warehouse. It is ready to use and requires no additional setup.
{'http://your-domain:3049'}.
docker/README.md for the defaults.
true if you don't want to allow new users to sign up.
INGEST_REPOSITORY_URL is an URL of console's export endpoint that returns configuration of `streams-with-destinations` entities:
https://$console-endpoint/api/admin/export/streams-with-destinations.
INGEST_REPOSITORY_AUTH_TOKEN is used to authorize request to console. It must start with service-admin-account: prefix.
E.g.: service-admin-account:console-token
See also CONSOLE_AUTH_TOKENS of console configuration
INGEST_REPOSITORY_URL.
host:port.
{'{"mechanism": "SCRAM-SHA-256", "username": "user", "password": "password"}'}
URL template of function servers managed
by the Operator. The default value matches the Kubernetes services the Operator creates.
Used for running functions of device destinations. Replaces INGEST_ROTOR_URL of previous Jitsu versions.
Used to authorize HTTP-requests to function servers.
See ROTOR_AUTH_TOKENS, ROTOR_TOKEN_SECRET and ROTOR_RAW_AUTH_TOKENS in the Rotor section
clickhouse.example.com:9440
INGEST_FAILOVER_LOGGER_ENABLED-falseINGEST_FAILOVER_LOGGER_ROTATION_PERIOD_MINUTES-60INGEST_FAILOVER_LOGGER_MAX_SIZE_MB-100INGEST_FAILOVER_LOGGER_COMPRESS-true
INGEST_FAILOVER_LOGGER_BASE_PATH-/tmp/kafka_failoverINGEST_FAILOVER_LOGGER_LOCAL_MAX_OLD_FILES-10
rotor (Kafka consumer, the main event pipeline), functions (function
server — set by the Operator) or profiles (profile builder server).
fetch() calls made from user functions.
ROTOR_AUTH_TOKENS is a list of hashed auth tokens that authorizes user in HTTP interface separated by comma. Each must have format:
$salt.$hash where $salt should be random string. Hash is hex(sha512($token + $salt + ROTOR_TOKEN_SECRET).
To hash token, use following command in the root of this repository: pnpm install && ROTOR_TOKEN_SECRET=xxxx pnpm tool:hash $token
ROTOR_RAW_AUTH_TOKENS can be used instead of ROTOR_AUTH_TOKENS to provide a comma-separared list of raw takens instead of hases. It offers simplicity at cost of
lower security.
REPOSITORY_BASE_URL is an URL of console's export endpoint that returns configuration of `streams-with-destinations` entities:
https://$console-endpoint/api/admin/export.
REPOSITORY_AUTH_TOKEN is used to authorize request to console. It must start with service-admin-account: prefix.
E.g.: service-admin-account:console-token
See also CONSOLE_AUTH_TOKENS of console configuration
clickhouse.example.com:9440
Only HTTP(s) protocol is supported.
BULKER_URL is an URL of Bulker service. Rotor will use it to send event intended to warehouse destinations
BULKER_AUTH_KEY is user to authentificated HTTP-request to Bulker. Should be one of{" "}
BULKER_AUTH_KEYS you configured in Bulker
host:port.
KAFKA_SSL_CA is a certificate in PEM format, KAFKA_SSL_CA_FILE is a path to the file with the certificate.
{'{"mechanism": "SCRAM-SHA-256", "username": "user", "password": "password"}'}
MongoDB is used for Functions Persistent Storage and Identity Stitching.
The value starts with mongodb:// and has the following format: mongodb://$user:$password@$host:$port/$database
To smoothly migrate from REDIS_URL you need to set REDIS_URL and MONGODB_URL at the same time.
Rotor will look for records both in MongoDB and Redis, but new records will be added only to MongoDB.
When you are sure that MongoDB is populated with enough data, you can remove REDIS_URL from the configuration.
redis://: redis://$user:$password:localhost:6379.Redis Sentinel Address: `sentinel1:26379,sentinel2:26379,sentinel3:26379`
Can be used for Functions Persistent Storage as alternative to MongoDB.
clickhouse destination is supported.{" "}
If you don't want to send metrics, you can skip this option.
MESSAGES_RETRY_COUNT is 3 and base is 10, then retry delays will be 10, 100, 1000 minutes
MAXMIND_LICENSE_KEY, from custom `MAXMIND_URL` or from S3 or compatible storage.
text or json
https://your-domain/
CONSOLE_AUTH_TOKENS is a list of hashed auth tokens that authorizes user in HTTP interface separated by comma. Each must have format:
$salt.$hash where $salt should be random string. Hash is hex(sha512($token + $salt + CONSOLE_TOKEN_SECRET).
To hash token, use following command in the root of this repository: pnpm install && CONSOLE_TOKEN_SECRET=xxxx pnpm tool:hash $token
CONSOLE_RAW_AUTH_TOKENS can be used instead of CONSOLE_AUTH_TOKENS to provide a comma-separared list of raw takens instead of hases. It offers simplicity at cost of
lower security.
PostgreSQL connection string. postgres://$user:$password@localhost:$port/database?sslmode=no-verify&schema=newjitsu
schema must be newjitsu, and sslmode must be no-verify
BULKER_URL is an url of Bulker service. Used for pulling event logs. E.g.: https://bulker.your-domain.com
BULKER_AUTH_KEY is used to authorized HTTP-request to Bulker. See BULKER_AUTH_TOKENS, BULKER_TOKEN_SECRET and BULKER_RAW_AUTH_TOKENS
in Bulker configuration
ROTOR_URL is an url of the Rotor service. E.g.: http://rotor:3401
ROTOR_AUTH_KEY is used to authorized HTTP-request to Rotor. See ROTOR_AUTH_TOKENS, ROTOR_TOKEN_SECRET and ROTOR_RAW_AUTH_TOKENS in the Rotor section
To enable GitHub OAuth for Jitsu.
You'll need to create a GitHub OAuth application to get those values:
- Go to GitHub Developer settings » OAuth Apps » New OAuth App.
- Put any value to
Application name. - Set
Homepage URLandAuthorization callback URLwith value ofJITSU_PUBLIC_URL. - Press
Register applicationbutton. - Press
Generate a new client secretbutton. - Copy
Client IDandClient Secretvalues to.envfile toGITHUB_CLIENT_IDandGITHUB_CLIENT_SECRETvariables respectively.
To enable OpenID Connect based authentication for Jitsu.
Expected json object with the following properties: issuer (the issuer domain in valid URL format), clientId, and clientSecret
The well-known configuration endpoint for the provider is automatically set based on the issuer, and the default authorization request includes scopes for OpenID, email, and profile information.
Auth0 Example: {'{"issuer":"https://{yourDomain}.us.auth0.com/","clientId":"***","clientSecret":"***"}'}
Optionally scopes the auth session cookie (jitsu-auth) to a parent domain so that sibling apps running on its
subdomains can read the logged-in session. Example: jitsu.com makes the cookie available to use.jitsu.com,
app.jitsu.com, etc.
If not set, the cookie is scoped to the Console's own host (e.g. use.jitsu.com) and is shared with that host's subdomains.
Security: widening the cookie to a parent domain shares the session across all of that domain's subdomains — only set this to a domain you fully control.
INGEST_PUBLIC_URL param of `ingest` service for details.
true enables Connectors Syncs feature in Jitsu Console UI. Requires syncctl service.
Scheduled syncs are managed by syncctl as Kubernetes CronJobs — no external scheduler is needed
(the GOOGLE_SCHEDULER_KEY variable of previous Jitsu versions was removed).
SYNCS_ENABLED=true. SYNCCTL_URL is an URL of the main endpoint of Syncctl service. SYNCCTL_AUTH_KEY is Syncctl service authentication key: one
of SYNCCTL_AUTH_KEYS or SYNCCTL_RAW_AUTH_TOKENS configured in Syncctl
free (shared,
sharded function-server deployments) or dedicated (one deployment per workspace).
See the Operator section.
Maintenance mode: a JSON descriptor that switches the console API to read-only mode and shows a
maintenance page. MAINTENANCE takes the JSON inline; MAINTENANCE_CONFIG_FILE takes a path
to a JSON file (e.g. a mounted ConfigMap), so the mode can be toggled without restarting the console.
Replaces the JITSU_CONSOLE_READ_ONLY_UNTIL variable of previous Jitsu versions.
MINUTE_RATE_LIMIT_ENABLED=true); MINUTE_RATE_LIMIT_BASE (default 60) is the base
per-minute budget from which limits per auth type and HTTP method are derived.
true, rejects signups with personal email addresses (gmail.com, etc.) — a work
email is required.
clickhouse.example.com:9440
Only HTTP(s) protocol is supported.
jitsu_cluster
SMTP_CONNECTION_STRING is a connection string to SMTP server in format: smtp://user:password@localhost:587EMAIL_TRANSACTIONAL_SENDER is an email address that will be used as sender.EMAIL_TRANSACTIONAL_REPLY_TO (optional) is an email address that will be used as Reply-To.BCC_EMAIL (optional) is an email address where all emails will be sent as BCC.
text or json
A list of hashed auth tokens that authorizes user in HTTP interface separated by comma. Each must have format:
$salt.$hash where $salt should be random string. Hash is hex(sha512($token + $salt + SYNCCTL_TOKEN_SECRET). $token must consist only of letters, digits, underscore and dash
SYNCCTL_RAW_AUTH_TOKENS can be used if you want to provide a comma-separared list of raw takens instead of hases. It offers simplicity at cost of lower security.
PostgreSQL connection string. postgres://$user:$password@localhost:$port/database?sslmode=no-verify&search_path=newjitsu. Should be the same as DATABASE_URL for console
search_path must be newjitsu, and sslmode must be no-verify
SYNCCTL_DATABASE_URL. E.g. if you use localhost in SYNCCTL_DATABASE_URL
syncctl service itself runs in kubernetes cluster, you can skip this option or use local value.
SYNCCTL_REPOSITORY_BASE_URL is the URL of the console's export endpoint:
https://$console-endpoint/api/admin/export. Syncctl polls the syncs export and
reconciles Kubernetes CronJobs (one per scheduled sync, named sync-<syncId>) to match the
configured schedules. If not set, scheduled syncs are not managed — only ad-hoc runs work.
SYNCCTL_REPOSITORY_AUTH_TOKEN is used to authorize requests to console. It must start with the
service-admin-account: prefix. E.g.: service-admin-account:console-token
180000), Kubernetes retry limit for failed
jobs (default 0) and maximum random start jitter in seconds (default 60).
3000) and retention in days
(default 60). These settings were moved from console to syncctl.
text or json
/health, /ready, /status).
OPERATOR_REPOSITORY_BASE_URL is the URL of the console's export endpoint:
https://$console-endpoint/api/admin/export. The operator polls workspaces, connections and
functions from it.
OPERATOR_REPOSITORY_AUTH_TOKEN is used to authorize requests to console. It must start with the
service-admin-account: prefix.
FunctionsServer table there.
local — in-cluster
config), context name, and the namespace where function-server deployments are created.
ROTOR_MODE=functions.
FUNCTIONS_SERVER_URL_TEMPLATE configured on
Rotor, Ingest and Console.
free (shared, sharded
deployments) or dedicated (one deployment per workspace).
free class (default
1) and minimum replicas per deployment (default 2).
16; target CPU utilization 100).
mongobetween connection-pooling sidecar to each function-server pod.
ADMIN_REPOSITORY_URL is an URL of console's export endpoint that returns configuration of `streams-with-destinations` entities:
https://$console-endpoint/api/admin/export/streams-with-destinations.
ADMIN_REPOSITORY_AUTH_TOKEN is used to authorize request to console. It must start with service-admin-account: prefix.
E.g.: service-admin-account:console-token
See also CONSOLE_AUTH_TOKENS of console configuration
ADMIN_REPOSITORY_URL.
host:port.
{'{"mechanism": "SCRAM-SHA-256", "username": "user", "password": "password"}'}