API DocsWorkflow DevelopmentDiscussionsOne Codex PlatformOne Codex Python Library
API Docs

Using Webhooks

🚧

Ready for webhooks?

Currently, webhooks are only available for paid users and partners. Please contact us to get webhooks set up for your account.

Overview

In addition the above resources, we also allow users to set up webhooks and subscribe to Events that occur as your Samples and Analyses are processed by the platform. Events are a record of webhook payloads that have been delivered to relevant subscriptions and only exist if webhooks are configured (i.e., an account without webhooks turned on will have no events). By default, up to 30 days worth of events are available via the v1 API.

Subscribing to webhooks

Currently, it is possible to subscribe to individual event types or subscribe to all events (*). Webhooks POST to a specified http or https endpoint without authentication and are individually signed and timestamped so that you can verify that the webhooks were sent by One Codex and not a third party (see Checking Signatures). Please contact us in order to get started with webhooks for your account.

Event types

Currently the following event types exist:

  • sample.uploaded: When a sample is successfully uploaded or imported into the One Platform. This event means we have successfully received your data and started to process it.
  • analysis.succeeded: When an analysis finishes successfully. Successful analyses have a success: true property and their results may be retrieved via the API (see Retrieve Analysis Results).
  • analysis.failed: When an analysis finishes but is unsuccessful. Failed analyses will have /results that result in a 404 error and a success: false property. Note that an analysis.failed event may fire multiple times for the same analysis if it is retried by One Codex's processing (it may also succeed in the future if the failure was due, e.g., to hardware or other unexpected processing issues).

Note that the default "wildcard" subscriptions (*) may include additional event types in the future. When requesting that webhook setup for your account, please specify if you would like the subscription(s) to listen to all events or only select events.

The Event resource

The event resource contains the following fields:

PropertyDescription
$uri
string		The event ID encoded as an addressable URI
payload
object		The webhook payload (as documented below). Note that webhooks will be delivered for a specific API version and that version is noted in the payload via the api_version field. Only v1 API version payloads, however, will appear in the /v1/events API.
status
string		An enum with one of the following 4 values:
success: Successful POSTs were made to all subscriptions (all returned 200 OK).

failed: At least one subscription returned a non-200 HTTP status code or connection error for every POST attempt made, and all retries were exhausted.
retryable: At least one subscription POST failed, but there are still retries remaining before the Event will be marked as failed.

pending: There is at least one subscription to this Event, and no attempts have yet been made to send out POSTs.

The Webhook payload format

The webhook payload delivered by our system consists of 5 fields:

api_version
string		The API version used in generating the representation of the relevant object field.
event_type
string		A string with the event type. Note webhooks may be configured to listen to all or only specific event types.
object
object		A representation of the core object for which the event_type was triggered for the specified api_version.
object_type
string		A string representation of the object type. Currently sample and analysis are the only supported values, indicating that the object is a Sample Resource or Analysis Resource, respectively.
triggered_at
date-time		Timestamp for when the event was triggered, encoded as a RFC 3339 timestamp. Note: The triggered_at field is not when the webhook was sent (which may be later due to retries or processing delays). The timestamp for the payload POST is included in the X-OneCodex-Signature HTTP header (see Checking Signatures below).

In production settings, we strongly recommend checking the signatures of any received webhooks to ensure that they originate from One Codex and not a malicious third party. See the following section for details.