# Destinations

Where kwery delivers your data. Pick the destination that matches how your team consumes
results — you can mix destinations across jobs and subscriptions.

## Webhooks

The default, self-serve destination. kwery pushes batch results and
[change events](/guides/change-events) directly to an HTTPS endpoint you control, signed with
HMAC-SHA256 so you can verify authenticity.

- Streaming batch results: [Webhooks](/guides/webhooks).
- Product monitoring: [Change events](/guides/change-events).


Both share the same transport — signed headers, `2xx` acknowledgment, and the same retry and
replay behavior. No setup on our side beyond a `callback_url` at submission time.

## Object storage

> **Rolling out.** Bucket destinations are configured per account and are being enabled
gradually — this is not yet a self-serve toggle. [Contact us](https://kwery.co/contact)
to have one set up.


For workflows that want files rather than HTTP callbacks, kwery can land results directly in
a bucket you own — Amazon S3 or Google Cloud Storage. Each delivery is written as a file (one
per batch, using the same structure as a stream delivery) instead of being POSTed to an
endpoint.

You provide the bucket and write credentials (an IAM role/policy for S3, a service account for
GCS); kwery writes into a prefix you specify. Contact us to have a bucket destination attached
to your account.

## Analytics & BI integrations — BigQuery, Snowflake, SQL, Tableau 

> **Enterprise plan only.** Everything in this section is a **managed pipeline** configured
per account by the kwery team — it is not a self-serve toggle and not wired up through the
API. [Contact sales](https://kwery.co/contact) with your target system, expected volume,
and schema preferences.


### How the pipelines work 

All analytics destinations are built on the same mechanism: every completed job's results
are exported in kwery's **normalized result schema** (the same fields documented per source
under [Sources](/sources#how-to-read-the-field-tables), one row per result, offers
flattenable to one row per offer) and loaded into your system on the **same cadence your
jobs run** — a job completes, its results land. No polling, no ongoing action on your side.

### Data warehouses 

- **BigQuery** — we load into a dataset in your GCP project. You grant a kwery service
account `roles/bigquery.dataEditor` on that dataset; tables are per result type
(`results`, `offers`, optionally `change_events` and `crawl_provenance`), partitioned by
observation date and clustered by `source, country`. Schema mapping is agreed at setup
and versioned — additive changes only, announced in advance.
- **Snowflake** — delivery via an external stage (S3/GCS) plus managed `COPY INTO` your
schema, or a Snowflake share, depending on your access model. Same table layout as
BigQuery.
- **SQL databases (Postgres, MySQL, SQL Server)** — for teams without a warehouse, a
managed loader writes into tables in a database you host. You provide a connection with
write access to a dedicated schema; upsert keys and retention are agreed at setup.


### BI & analytics tools — Tableau, Power BI, Looker, Metabase 

BI tools don't connect to kwery directly — they connect to **where the pipeline lands your
data** (the warehouse or SQL database above), using each tool's native connector. That's a
deliberate design: your dashboards run on your infrastructure at your warehouse's speed,
joined against your own margin/catalog tables, with no kwery credentials inside the BI tool.
As part of Enterprise onboarding we hand over the table documentation and a set of starter
queries (current cheapest offer per SKU, price-position vs. competitors, offer-count trends)
that map 1:1 onto Tableau/Power BI/Looker data sources.

### File-based export (S3 / GCS) 

The [object storage](#object-storage) destination doubles as the integration path for
anything that ingests files: deliveries are written as **NDJSON** (one result per line, the
exact stream-delivery shape; CSV on request) under a date-partitioned prefix in your bucket,
e.g. `s3://your-bucket/kwery/2026/08/20/{job_id}.ndjson`. Spark, Athena, DuckDB, or a plain
cron loader can pick them up from there.

### What the setup process looks like 

1. You tell us the target (BigQuery / Snowflake / SQL / files) and grant the scoped access
described above — we never need more than write access to the agreed destination.
2. We configure the pipeline against your schema preferences and backfill a sample so your
team can validate the mapping.
3. From then on it runs unattended; schema changes are additive and announced. Delivery
health is monitored on our side like any other delivery channel.


## Next steps

- [Webhooks](/guides/webhooks) — HMAC verification, retry schedule, replay.
- [Change events](/guides/change-events) — event catalog and payload shapes.
- [Authentication](/guides/authentication) — credentials and account setup.