Using Continuous Query

Junction Sense is in closed beta.Interested in Junction Sense? Get in touch with your Customer Success Manager.

You can create a Continuous Query to have your Junction Sense Query automatically evaluated by Junction as needed, and receive any query result changes through your Webhook or ETL Pipeline destinations.

Automatic Evaluation

Continuous Query runs automatically on all existing and new Users in your Team.

Continuous Change Monitoring

Continuous Query is scheduled intelligently in response to any new data points or updates discovered through device data connections made through Junction Link and Junction Mobile SDKs.

Result Pushing

Junction pushes any Continuous Query result table changes to your Webhook or ETL Pipeline destinations.

Result Pulling

The latest result table can be queried through Junction API at any time.

A high-level illustration of the continuous query structure

With Continuous Query, you can focus on adding value to your product with the aggregated data insights:

No need to build your own scalable data pipeline from scratch to ingest, store, and aggregate standardized device data.
No need to poll the Query API to receive query results.

Continuous Query requirements

While Continuous Query uses the same Query DSL as the Query API, some restrictions are in place:

The query must group by a truncated datetime.
The query must select all group key columns.

An ungrouped Readiness Scores query is a supported exception when it directly selects the date column and readiness values. See Readiness Scores.

Please reach out if your use case is limited by these restrictions.

Subscribing to query result changes

When a Continuous Query is re-evaluated and the result set has changed, Junction sends a Result Table Changed data event to your Webhook or ETL Pipeline destinations. This data event includes only the delta (new rows or changed rows with respect to the group keys). To re-fetch the whole result set, use the Get Result Table endpoint. Treat this event as a notification that the result table changed, not as an ordered event log:

The event does not include a query evaluation timestamp, sequence number, result version, or task ID.
Webhook delivery can be retried or arrive out of order. Deduplicate webhook retries with the svix-id header; do not use svix-timestamp as query evaluation time or an ordering key.
Fetch the latest result table before making a stateful workflow decision. This prevents an older or retried delivery from regressing application state.
The data object uses columnar JSON. Arrays at the same position form one row. For example, index 0 in every array belongs to the same changed row.

If you only need to trigger a refresh, enqueue the query_id and user_id, return a successful response promptly, and fetch the current table asynchronously.

{
  "event_type": "continuous_query.result_table.changed",
  "user_id": "4a29dbc7-6db3-4c83-bfac-70a20a4be1b2",
  "client_user_id": "01HW3FSNVCHC3B2QB5N0ZAAAVG",
  "team_id": "6b74423d-0504-4470-9afb-477252ccf67a",
  "data": [
    {
      "data": {
        "group_key.0": [
          "2025-02-17T00:00:00"
        ],
        "mean.efficiency": [
          98.22
        ],
        "mean.sleep_score": [
          76.75
        ],
        "min.sleep_score": [
          61
        ],
        "newest.chronotype": [
          "third"
        ]
      },
      "query_id": "b59425f8-eb5a-4c60-ae95-eda70179da04",
      "query_slug": "sleep-analysis-v1"
    }
  ]
}

Managing your Continuous Queries

You can manage your Continuous Query using our Org Management API:

You can also manage them through the Continuous Query section of the Junction Dashboard:

​Continuous Query requirements

​Subscribing to query result changes

​Managing your Continuous Queries

Continuous Query requirements

Subscribing to query result changes

Managing your Continuous Queries