Silverfin supports a range of webhook events which allow you to track changes in your environment, and can function as a trigger for your own API flows based on such an event.
Currently the Sync API supports the following webhook events:
Event | Description |
---|---|
sync.requested | a sync is requested on Silverfin (automatic nightly sync or by a customer from the UI) |
sync.company_added | a company on Silverfin was configured to use that Sync API |
sync.company_removed | a company on Silverfin is no longer using the Sync API |
The endpoint will send a POST request with a JSON payload to a specified target URL
. It will always include the webhook
, event
and company
sections. The document section mentioned in the example below is specific to events related to documents.
{
"webhook": {
"id": 1052767529,
"url": "http://localhost:3001/webhook",
"events": [
"sync.requested",
"sync.company_added",
"sync.company_removed"
],
"user_id": 554005444,
"expired_at": null
},
"event": "sync.company_added",
"company": {
"id": 398393022,
"name": "Demo Company"
}
}
Webhook signature verification
Every request must include two signature headers: X-SF-SIGNATURE-1
and X-SF-SIGNATURE-2
. These signatures are generated using your application's webhook_signing_token_1 and webhook_signing_token_2, respectively.
To confirm the authenticity of a request originating from Silverfin, you should compute its Hash-based Message Authentication Code (HMAC) using the SHA-256 digest algorithm, the request's body as data, and a webhook signing token as the key. For instance, in Ruby, you can achieve this as shown below:
OpenSSL::HMAC.hexdigest(OpenSSL::Digest.new('sha256'), WEBHOOK_SIGNING_TOKEN, REQUEST_BODY)
If at least one of the computed signatures matches its respective header, you can consider the request as authentic. Matching with a single signature allows for a seamless rotation of your application's webhook signing tokens.
Retry strategy
When the endpoint doesn't reply with a 2xx
code, the post will be retried with an exponential back-off over a total duration of ~48 hours. If after this time the endpoint still doesn't reply with a 2xx code
, the webhook subscription will be marked as expired (disabled). Also note that an expired webhook subscription can't be revived, only deleted. To restore its functionality, the subscription will need to be re-created anew.
Throttling
Silverfin does not throttle outbound webhook events. To protect your application from occasional spikes in incoming events, you may wish to build your own solution or use a third-party service.
Timeouts
Silverfin requires the webhook receiving server to reply within a reasonable time. If the server takes too long to respond, the webhook event will be failed and be retried according to the Retry strategy described above. To avoid timeouts, you should defer processing of the payload until the server replies