For the complete documentation index, see llms.txt. This page is also available as Markdown.

Custom Webhook

The Custom Webhook connector lets you ingest events from any third-party system via a dedicated HTTPS endpoint. QUANTI: automatically generates the receiving URL, infers the schema from your first test payload, and routes the data directly into your data warehouse.

Typical use cases: CRM events, application alerts, web forms, e-commerce notifications, exports from third-party platforms that do not have a native QUANTI: connector.

To ingest data from the QUANTI: web tracking tag, use the dedicated Real-Time Analytics connector — it natively handles sessions, attribution, and consent.


How it works

  1. QUANTI: generates a unique HTTPS endpoint for your tenant

  2. You configure your source's webhook to POST or GET payloads to that URL

  3. On receipt of the first payload, QUANTI: automatically infers the schema (field names and types)

  4. You validate the schema and the connector starts ingesting

Each received payload is inserted as-is into your data warehouse, without transformation. Fields are mapped directly from the JSON structure of the payload.


Setup

1

Name your tenant

Give your webhook connector a name (e.g. crm-events, shop-notifications). This name is used as the table name in your warehouse and cannot be changed after creation. Choose a name that is lowercase, alphanumeric, and uses hyphens as separators.

2

Retrieve the endpoint URL

Once the connector is created, QUANTI: provides a dedicated HTTPS endpoint URL in the format:

https://webhook.quanti.io/<tenant-id>/<connector-slug>

This URL is unique to your connector. Copy it and paste it into the webhook configuration of your source system.

3

Send a test payload

Trigger an event from your source or manually send a representative JSON payload using cURL or Postman:

curl -X POST https://webhook.quanti.io/<your-endpoint> \
  -H "Content-Type: application/json" \
  -d '{
    "event": "order.created",
    "order_id": "12345",
    "amount": 99.90,
    "currency": "EUR",
    "customer": {
      "email": "user@example.com",
      "country": "FR"
    }
  }'

A 200 OK response confirms the payload was received. If you receive a 400, check that the body is valid JSON and that the Content-Type header is set to application/json.

4

Validate the inferred schema

QUANTI: displays the schema detected from your first payload. Review the inferred field names and types (STRING, NUMERIC, BOOLEAN, TIMESTAMP, RECORD…) and confirm to activate ingestion.


Endpoint URL format

The endpoint URL generated by QUANTI: follows this structure:

Segment
Description

tenant-id

Unique identifier of your QUANTI: workspace

connector-slug

The name you gave the connector during setup

The URL is static and does not change. If you need to change the connector name, you must create a new connector.


Payload format

Property
Value

HTTP method

POST or GET

Content-Type

application/json

Maximum payload size

1 MB

Encoding

UTF-8

Nested objects and arrays

QUANTI: handles nested JSON structures. By default:

  • Nested objects are flattened using dot notation (e.g. customer.email, customer.country)

  • Arrays of primitives are stored as a JSON string in a single STRING column

  • Arrays of objects are stored as a RECORD (REPEATED) column in BigQuery

If the flattening behaviour does not match your needs, you can override it in the schema configuration after the first payload is received.


Schema management

Adding new fields

If your source starts sending a new field that was not present in the initial payload, QUANTI: automatically adds the corresponding column to the warehouse table. No action is required.

Changing field types

Type changes (e.g. a field that was STRING and becomes NUMERIC) are not applied automatically to avoid breaking downstream queries. If you need to change a column type, contact support or update the schema manually in the connector settings.

Removing fields

Columns are never automatically removed from the warehouse table, even if a field stops appearing in payloads. Missing fields will simply produce NULL values in those rows.

Minimum field presence threshold

QUANTI: applies a minimum field presence threshold to filter out incomplete or malformed payloads. A payload must contain at least 30% of the fields defined in the schema to be accepted and written to the warehouse. Payloads below this threshold are silently dropped.


HTTP response codes

Code
Meaning

200 OK

Payload received and queued for ingestion

400 Bad Request

Payload is not valid JSON or Content-Type is missing

413 Payload Too Large

Payload exceeds the 1 MB limit

503 Service Unavailable

Temporary QUANTI: ingestion issue — retry with backoff

Your source system should be configured to retry on 5xx responses. QUANTI: returns 200 immediately upon receipt, before the payload is written to the warehouse, so there is no risk of duplicate insertion from retries at the HTTP level.


Data in the warehouse

Each received event generates one row in your BigQuery table. QUANTI: automatically adds the following system columns:

Column
Type
Description

_quanti_received_at

TIMESTAMP

UTC timestamp of receipt by the QUANTI: endpoint

_quanti_id

STRING

Unique identifier generated for each event (UUID v4)

All other columns correspond to the fields in your JSON payload. Nested object keys are flattened into column names using dot notation.


Limitations

  • No lookback: only events received after the connector is activated are stored. There is no backfill of historical events.

  • No deduplication: if your source can send the same event multiple times, identical rows will be created. Handle idempotency in your downstream pipeline using _quanti_id.

  • No transformation: payloads are written as-is. Field renaming, filtering, or enrichment must be done downstream in your warehouse.

  • Rate limit: QUANTI: accepts up to 500 events per second per connector. Contact support for higher throughput requirements.

Last updated