Contact Login
Integration directory

Webhooks

Deliver approved Queast context to an endpoint you control

Queast lists Generic Webhook as a supported manual connector in the current product. It can send a validated outbound event envelope to a configured endpoint, while public plan availability and the exact event and payload contract must be confirmed before implementation.

Talk to us about Webhooks

Current connector status

Separate product support from implementation scope

The current product catalog and settings UI verify a connector foundation. They do not establish the same event access, payload fields, operating limits, or support terms for every customer.

VerifiedConnector catalog
Generic Webhook is marked supported in the current product UI.
VerifiedTenant access
Integrations must be enabled for the tenant.
VerifiedManual setup
A tenant administrator configures a destination URL and may add a write-only signing secret.
ConfirmPublic availability
Plan and market availability are not approved for publication; confirm with Queast.
ConfirmPublic contract
The customer-facing outbound event and field catalog must be approved per implementation.

Outbound delivery path

Keep a boundary on both sides of transport

A configured Webhook carries an already-authorized artifact through a validated envelope. The receiving system remains responsible for verification, duplicate handling, and its next workflow.

  1. 01Queast authority

    Authorized artifact

    Queast selects an artifact that the tenant and connection are permitted to deliver.

  2. 02Transport

    Validated envelope

    The implementation validates a v1 event shape and preserves event, schema, time, tenant, and idempotency context.

  3. 03Transport

    Configured controls

    The connection supplies its endpoint and, when configured, a write-only secret for request signing.

  4. 04Customer authority

    Customer endpoint

    The receiver verifies the request, deduplicates under its own policy, and decides what workflow may continue.

Verified delivery foundation

Use the controls that are actually implemented

These controls are present in the current implementation. Their public configuration and operating policy still need an approved contract.

Implemented foundation

Envelope metadata

The v1 foundation carries event and schema identifiers, event and production times, tenant and idempotency context, plus event-specific data.

When configured

Optional signing

When a secret is configured, Queast adds a timestamp and v1 HMAC-SHA256 signature calculated over the timestamp and raw body.

Implemented foundation

Idempotent dispatch support

Delivery jobs are deduplicated within a tenant and connection, and the request includes the job idempotency key. This is not an exactly-once receiver guarantee.

Implemented foundation

Recorded attempts

Jobs and attempts retain operational status, attempt timing, response status, and bounded body metadata without exposing raw bodies in normal public logs.

Failure-state boundary

Review delivery state without assuming a guarantee

The worker distinguishes outcome states and can schedule retryable failures for another attempt. Exact timing, limits, retention, alerting, replay, and SLA remain contract decisions.

Success

A successful attempt records completion and the receiver response status.

Retryable

Temporary transport or eligible response failures can return to the delivery queue.

Non-retryable

Permanent request or configuration failures do not silently pass as success.

Quarantined

Exhausted or non-retryable jobs can remain visible as a held operational state.

Artifact authority

Transport context without raising its authority

A webhook does not create evidence, recompute analysis, activate a Composite Intent, satisfy Signal eligibility, or turn lower-authority context into an Actionable Signal.

  1. 01

    Source evidence

    The observation keeps its source, date, and provenance.

  2. 02

    Analysis

    Interpretation remains separate and may connect multiple inputs across time.

  3. 03

    Composite Intent

    The company-level hypothesis keeps its time-aware lifecycle, conflicts, and provenance.

  4. 04

    Actionable Signal

    Only a recommendation that passed the applicable eligibility contract carries strict Signal authority.

  5. 05

    Webhook delivery

    The configured connection carries the approved artifact and declared metadata without increasing its authority.

  6. 06

    Receiving workflow

    The customer-controlled system verifies the request and decides what happens next.

Explore Actionable Signals See Daily Workbench

Receiver checklist

Confirm the full contract before connecting

These are implementation questions, not promises that every Webhook connection exposes the same events or operating behavior.

Read Tech and Security
  • 1

    Availability and events

    Which plan, tenant, market, and outbound event types are enabled?

  • 2

    Payload and privacy

    Which fields, person-data controls, schema versions, and change policy apply?

  • 3

    Request verification

    Is signing required, how is the secret rotated, and what timestamp tolerance applies?

  • 4

    Duplicate handling

    Which idempotency key must the receiver persist, and for how long?

  • 5

    Operations

    What timeout, retry, quarantine, replay, retention, alerting, rate-limit, support, and SLA behavior applies?

  • 6

    Endpoint policy

    Which URL, network, and receiver-security requirements must be met?

Next step

Verify the Webhook contract with Queast

Confirm availability, events, fields, privacy, request verification, duplicate handling, and operating behavior before implementation.

Talk to us about Webhooks Explore all integrations