Integrations and export

Integrations and export continuously sends data the platform produces to the enterprise's own systems, for example Kafka, Elasticsearch, a cloud log service, SIEM, object storage, or an observability platform. The platform and a tenant each have one page, with the same structure. Their data is not visible to each other:

A platform administrator cannot see any tenant's integration entries or send counts. A tenant administrator sees only this tenant's entries. Export data on the platform page is the only entry that can read tenant data; see Export data below.

The page has two tabs, Enabled and Export records. Upper right is Export data and New integration.

Agent run logs are provided only in Zenova. The Zentrix Gateway catalog does not have this item.

Connect a destination

1. Click New integration in the upper right to enter the create page. The left column lists every product by category, searchable by name. A count of already-configured entries is shown next to the product. Unavailable products are greyed out with a reason. Choose a product, for example Alibaba Cloud Kafka.
2. In the right column fill in connection information and credentials. Field notes are shown with the form. Default endpoints of common products are prefilled.
3. Choose data to send. Call records can be filtered by department (including its descendants), or only failed calls can be sent. Other data has no filter and is sent as every record.
4. Choose a start: From now sends only data produced after enable. Backfill from the retention start first backfills every historical record in that data class's retention window, then continuously sends new data. When several data classes are selected, the backfill start is the latest of their retention starts.
5. Click Test send. The platform checks in four steps — Address resolution and egress check → Establish connection → Authenticate → Write a test record — and shows results step by step. The test record is marked "test": true.
6. Enable can be clicked only after the test passes. The test result is valid for 15 minutes. Changing a connection field or credential after the test requires testing again.
7. After save, return to the list page. When the form has unsaved changes, clicking back or cancel asks for confirmation first.

When editing an existing entry, click Edit in the row menu or the detail to enter the edit page. The product cannot be changed. For credentials, fill in only the fields you are replacing; blank fields keep the saved values.

Each tenant may configure at most 20 entries. After the cap, every product in the create-page left column is unavailable, with a reason shown.

How it runs and delivery semantics

• Realtime: sending starts about 10 seconds after data is stored. The platform advances to the next batch only after the other side confirms receipt. During a destination outage, data is kept on the platform side. After recovery, sending continues from the interruption. Nothing is lost.
• Scheduled report: at a named time of day, week, or month, one report file is generated and delivered to object storage, a webhook, or Platform-hosted download. Only call records and hourly usage are supported: call records export as NDJSON and can be filtered by end user; hourly usage can export as CSV or NDJSON, with a choice of roll-up and filters. Connection fields and credentials for object storage and webhook are identical to realtime mode. A webhook completion notice must be signed; fill in a signing secret.

A scheduled report suits periodic delivery. When you only need one file once, use Export data below. You do not need a new entry.

Scheduled jobs from the former Report export page have all been converted to scheduled reports. Plan and destination stay the same. Reports delivered to platform-hosted download keep their previous enabled state. Object-storage reports migrated from the former report export need service address, region, and access key completed in edit before they can be enabled again. Webhook reports need a signing secret filled in before they can be enabled again. Until that is completed, the detail shows Connection incomplete, and Resume and Run now are unavailable.

Delivery semantics are decided by the destination. The confirmation dialog before re-export states this:

Every record carries a stable record ID. Elasticsearch document ID, Kafka message key, and the id field in a webhook payload all use it.

Export data

Export data generates one ZIP file once. It suits a one-off extract, reconciliation, and audit evidence. You do not need a new integration entry.

1. Click Export data in the upper right.
2. Choose data and format: call records export as NDJSON and can be filtered by end user; hourly usage can export as CSV or NDJSON, with a choice of roll-up.
3. Choose start time and end time. A single export is at most 93 days. The end time cannot be later than now.
4. The platform page also chooses tenants: All tenants (default) or Named tenants (at most 100, searchable by name). The ZIP has one file per tenant. A tenant with no data still gets a file (CSV has only a header; NDJSON is empty), so "no data" can be told from "not exported".
5. Click Start export. The page switches to the Export records tab. A new record shows queued, running, then success, and the page refreshes status automatically.
6. After success, click Download to get the ZIP. The file is kept 90 days. After expiry it shows File expired, download is unavailable, and Re-export can generate another with the same conditions.

On failure the record shows the reason, for example data in the window has passed retention and been cleaned, the per-export row cap was exceeded (the platform page sums every selected tenant), a data read failed, or platform storage is not configured. When the row cap is exceeded, shorten the window or reduce tenants and export again. Deleting a record also deletes the file.

Create, delete, and download of an export are all written to operation audit.

Status

Failure reasons are: destination unreachable, authentication rejected, the other side returned an error, the other side refused the data, send timed out. When authentication is rejected, replace credentials in edit. Replacing credentials does not cause a resend.

Re-export

In the entry detail choose Re-export. After choosing a start time, the platform shows the estimated count and a duplicate hint. After confirm, it resends every selected data class from that time. During re-export the status is Re-exporting. After it catches up it returns to Healthy automatically. The same entry can have only one re-export at a time.

When changing the destination address or adding or removing a data class, the platform prompts that it will resend from the start; it takes effect after confirm. Changing only the name, a filter, or credentials does not resend.

Platform catalog

The platform page Enabled table also lists Sentry error reporting. Operations match other entries.

Tenant catalog

Client-session observation

Client-session observation is sent as complete events, including session bodies. Before enabling, confirm that the destination's access control and retention meet the enterprise's data requirements.

Network and security

• A destination address a tenant fills in cannot point at a platform-internal service, a reserved intranet address, or a built-in component of the deployment. Node addresses a Kafka cluster returns, and virtual-hosted object-storage addresses, are under the same restriction. When refused, the failure reason shows Destination unreachable.
• The platform does not follow redirects the destination returns.
• Credentials are stored in the platform secret service. They are not echoed on edit.
• Each tenant's send-rate cap is 2,000 records per second; the platform cap is 20,000 per second. Overflow is deferred to the next period and is not dropped.