You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: README.md
+119-1Lines changed: 119 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -280,9 +280,127 @@ This section covers how to define new BillingCycleTemplates, control existing Bi
280
280
281
281
## Subscribing to Webhooks
282
282
This section covers how to receive dynamic updates from Inbox Health via REST API webhooks that ensure API clients are immediately informed upon changes of relevant records in Inbox Health. Whether the change originates from a patient, provider, administrator or automated system these webhooks are triggered and immediately provide feedback
283
+
284
+
## X-InboxHealth-Signature Header
285
+
This section will explain the steps required to reproduce the header X-InboxHealth-Signature which is used to verify that all webhook event requests coming from Inbox Health are authentic and haven’t been tampered with. The X-InboxHealth-Signature header is generated using the HMAC-SHA1 hashing algorithm, with the base signature being generated from the request URL and the POST body parameters, using your secret API key as the signing key.
286
+
287
+
The webhook event we will be demonstrating with will be a `patient_created` event with dummy JSON data to represent what a typical event would actually look like. The raw request looks like this
All webhook events sent by InboxHealth will be via a POST HTTP Method. The exact URL of the request is used as part of the base signature. So in our current example, the URL used would be https://coolcompany.com/api/v1/webhooks
299
+
300
+
#### Collecting Parameters
301
+
302
+
The second part of creating the base signature is collecting the request parameters, which are sorted and concatenated into a normalized string using the following rules:
303
+
304
+
URL encode every key and value
305
+
Parameters are sorted by name, using lexicographical byte value ordering. If two or more parameters share the same name, they are sorted by their value
306
+
Parameters are concatenated in their sorted order into a single string. For each parameter, the name is separated from the corresponding value by an '=' character (ASCII code 61), even if the value is empty. Each name-value pair is separated by an '&' character (ASCII code 38)
307
+
308
+
Given our example POST body above, these parameters would be normalized into the following single string
Since we based our normalization rules off of the OAuth specification, we leverage the OAuth Ruby library for normalizing the parameters. The method can be viewed on GitHub at https://github.com/oauth-xx/oauth-ruby/blob/master/lib/oauth/helper.rb#L44 for further education on the normalizing process.
385
+
386
+
#### The Signing Key
387
+
388
+
Your secret Inbox Health user API key is used as the signing key to the HMAC-SHA1 hashing algorithm. We determine which API key to sign with _based on the user that created, or last updated, the webhook endpoint in the Inbox Health Partner app._ As always, keep this key secret and safe!
389
+
390
+
#### Calculating the Signature
391
+
392
+
We can now calculate the final signature by passing the base string of our request URL and normalized request parameters to the HMAC-SHA1 hashing algorithm, using the user API key as the signing key. Please note, HMAC will output in binary string, so we convert it to base64.
and using an example API key of `api_key` as our signing key, the X-InboxHealth-Signature would be
399
+
400
+
`93G+w7p0GC2FB+us2KO8lT/XfZM=`
283
401
284
402
## FAQs
285
403
Please don't hesitate to ask questions via our email, Slack or GitHub Issues. We'll update this section with common questions as we work to flesh out our documentation.
286
404
287
405
## Forthcoming Documentation
288
-
We're currently working on more documentation, but between these initial examples and the swagger docs I hope you'll be able to get a decent start the feel of the API itself. Don't hesitate to contact us by email, GitHub Issues, or Slack for quicker responses.
406
+
We're currently working on more documentation, but between these initial examples and the swagger docs I hope you'll be able to get a decent feel of the API itself. Don't hesitate to contact us by email, GitHub Issues, or Slack for quicker responses.
0 commit comments