Clio Webhooks API
Webhooks are a way of detecting events in Clio without the need for polling. A webhook can be subscribed to a number of `events` on a model. Some events will be different depending on the chosen model, but (with one exception) *all* models support the following events: * `created` * `updated` * `deleted` To subscribe to any or all events for a model, [create a webhook record](#operation/Webhook#create) with the URL that you want webhooks to be sent to, a model, and the list of `events` you care about. Whenever an event happens on that model in Clio that the user is authorized to see, an HTTP request will be made to the supplied URL with details about the event. A webhook will automatically expire after a set period of time. If no `expires_at` parameter is provided, the webhook will expire after 3 days. The maximum duration you can set a webhook to expire after is 31 days. If you require longer than that, you can manually extend it by updating the `expires_at` field. ## Supported Models Your application needs to have the corresponding model OAuth scope when creating or updating a webhook. For example, when creating/updating a folder webhook you need the document Oauth Scope and the webhook Oauth Scope. The list of models supported by webhooks with their corresponding string identifier and ID is presented in the following table: | Name | String Identifier | ID | Oauth Scope | |-----------------------|-----------------------|:--:|----------------| | Matter | matter | 1 | Matters | | Activity | activity | 2 | Activities | | Bill | bill | 3 | Billing | | Calendar Entry | calendar_entry | 4 | Calendars | | Communication | communication | 5 | Communications | | Contact | contact | 6 | Contacts | | Task | task | 7 | Tasks | | Document | document | 8 | Documents | | Folder | folder | 9 | Documents | | Clio Payments payment | clio_payments_payment | 10 | Clio Payments | ## HTTPS Please note that all webhooks MUST be using a url with the `https` scheme. All other schemes, including `http`, will be rejected. ## Specifying Fields in Webhooks When a webhook is sent, the payload will not include the entire object for the record. To select specific fields from the record, you can use the fields parameter when creating the webhook. For example: when creating a webhook listening for new Activity records being created, you can pass the value “id,etag,quantity,price” into the fields parameter. When an Activity is created, the id, etag, quantity, and price fields of the new Activity will be included in the webhook's payload. For `update` webhooks, the fields parameter is also used to specify fields that will be “watched” by the webhook. Clio will only send a webhook when at least one of the selected fields has changed on a record. **An important note** If you have never received a webhook for an object before, you will receive a webhook for that object if any fields have changed on that object, including fields you haven't subscribed to. For example: if you create a webhook that subscribes to updates to Activities and provide "price" as the field parameter value, the first time an Activity is updated after the Webhook is live will trigger a webhook event – even if the price hasn't changed. Subsequent webhook events for that Activity will only be sent when the price field changes. Note that there is a hard limit to the size of the `fields` parameter. Any request containing a `fields` size over 1000 characters will be rejected. Tip: Use the minimum set of fields to reduce how frequently your endpoint is hit. ## Model Specific Events As mentioned previously, almost all models support the created, updated, and deleted events. Some models also support events specific to their life cycle. ### Clio Payments payments * `created` is fired whenever a payment is created * `updated` is fired whenever a payment is updated ### All other Models * `created` is fired whenever a model is created * `updated` is fired whenever a model is updated * `deleted` is fired whenever a model is deleted ### Matters * `matter_opened` is fired whenever a matter's status changes to "Open" * `matter_pended` is fired whenever a matter's status changes to "Pending" * `matter_closed` is fired whenever a matter's status changes to "Close" More model-specific events will be coming soon. ## Delivery Failure and Retries A response status code of `2xx`, `3xx`, or `410 GONE` indicate that the action was successfully processed. When a `410 GONE` response is received, the webhook subscription will be disabled. All other responses will be considered unsuccessful, and they will be retried using an exponential backoff strategy. ### Timeouts Clio will wait a short period of time before the request will timeout. We will consider it an unsuccessful response and retry using an exponential backoff strategy. It is important to respond quickly. Failure to do so repeatedly may result in your webhook being disabled. If you need to do lengthy processing with the webhook, it is recommended that you defer the processing until after you have sent a response back to Clio. ## Webhook Security ### Identity Confirmation To ensure that a URL actually intends to receive webhooks from Clio, and to ensure that the payloads are actually from Clio, we will share a secret in the initial handshake. A POST request will be made immediately after a webhook is setup, or whenever the URL changes. This request will have a unique secret in a `X-Hook-Secret` header along with the id of the webhook that was just created. There are two ways of confirming the webhook using this secret: #### Option 1: Immediate Upon initially receiving this secret, the endpoint can return a `200 OK` response and include the same secret in a `X-Hook-Secret` header. #### Option 2: Delayed After receiving the secret, make a PUT request to `/api/v4/webhooks/:webhook_id/activate` with the secret in a `X-Hook-Secret` header. Note that a webhook will not be enabled until this handshake is successful. ### Confirming Hook Legitimacy To prove that Clio is sending all subsequent messages, Clio will sign all of the requests. Clio will compute an [HMAC-SHA256 signature](https://en.wikipedia.org/wiki/Hash-based_message_authentication_code) based on the shared secret and the request body. That signature will then be placed in a `X-Hook-Signature` header. The endpoint can then verify the signature to know if the message is authentic. Verification is as simple as computing an HMAC-SHA256 signature using the shared secret as the key and the request body as the message, and comparing it to the `X-Hook-Signature` header. ## Examples A Webhook can be created for the Activities model, to trigger on any events and return the id and etag fields: ```http { "data":{ "url":"https://my/callback/url", "fields":"id,etag", "model":"activity", "events":["created","deleted","updated"] } } ``` This webhook would have the following responses for different actions. It would trigger on any events for the model, and return the id and etag fields for that model, and the event type. Notes: * The `model` field accepts both the string identifier of the model as in the example, or its ID. In the latter case, you would have provided the ID parameter: `"model":2`. Refer to [the table listing the models supported by webhooks](#section/Supported-Models) for matching the model name with its ID. ### Create In the event of an Activity being created, your URL would receive the following JSON: ```http { "data":{ "id":152, "etag":"\"9a103be2201ae758992733a91f02903f\"" }, "meta":{ "event":"created", "webhook_id":1234 } } ``` ### Update In the event of an Activity being updated, your URL would receive the following JSON: ```http { "data":{ "id":152, "etag":"\"9d9ef9fb42a505976d90d564c1596f11\"" }, "meta":{ "event":"updated", "webhook_id":1234 } } ``` ### Delete In the event of an Activity being deleted, your URL would receive the following JSON: ```http { "data":{ "id":152, "etag":"\"3cc31bfbd6cfc16d3d7123423e437079\"" }, "meta":{ "event":"deleted", "webhook_id":1234 } } ```