Webhooks are the mechanism in which out-of-band processes can communicate with an implemented service.
The incoming request will be signed and encrypted in the same manner as an outgoing request from the
API. See Cryptography for more information in that regard. All implementations
should verify the request utilizing the JWT provided in the Authorization header
of webhook requests.
The public key utilized to encrypt the webhook data is the same key utilized to initiate
the process that triggered the webhook. For example, if the webhook is for an authorization
response then the public key used to verify signature of the authorization request will be the
public key used to encrypt the authorization response webhook.
POST /launchkey/webhook HTTP/1.1
Authorization: IOV-JWT eyJhbGciOiJSU0EtT0FFUCIsIm.VuYyI6IkEyNTZHQ00ifQ.OKOawDo13gRp2ojaHV7LF
To allow for processing of webhooks with key rotation, an implementation must allow
processing webhooks from keys that may have expired between the time of the request initiating
the process and the triggering of the webhook.
Mutual TLS (optional)
If you want to secure incoming webhook requests from TruValidate Multifactor Authentication on your network, we provide mutual TLS.
All requests with webhook urls specified to use HTTPS will validate the server certificate. In addition, webhooks will
sign their requests with our own certificate. These can be verified on the Server’s end using the specified Subject
For Production webhooks the following SDN will be provided:
And for CI:
In some web servers iovation, Inc. may appear as iovationx5C, Inc.
In addition the DigiCert High Assurance EV Root CA
should be trusted with a verification depth of 2 due to the certs being signed by the DigiCert SHA2 High Assurance