Destinations

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

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

• Streaming batch results: Webhooks.
• Product monitoring: 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.

Rolling out. Bucket destinations are configured per account and are being enabled gradually — this is not yet a self-serve toggle. Contact us 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.

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 with your target system, expected volume, and schema preferences.

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, 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.

• 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 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.

The 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.

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.

• Webhooks — HMAC verification, retry schedule, replay.
• Change events — event catalog and payload shapes.
• Authentication — credentials and account setup.