Applications can receive real-time notifications whenever a transaction is processed or updated via the InstaMed Webhook interface.

With webhooks enabled, InstaMed sends a simple HTTP POST containing the relevant transaction information (i.e. Patient info, Amount, Transaction Date, TransactionID, etc) to the application URL in the requested format (JSON, XML, NVP).

Response and Error Handling

Return a HTTP status code 200 only if you successfully store the webhook message. If the HTTP post is not successfully stored, return “Status-Code” indicating the post was not successful (ex. “400” or “500”). Along with a standard HTTP “Status Code” optionally include a “Response Phrase” which InstaMed can parse and pass as the Webhook Posting Message for client review and reference.

If the initial webhook post is unsuccessful, InstaMed retries the webhook post every 30 minutes for up to five attempts. InstaMed assigns the transaction a pending posting retry workflow status when a message is being re-attempted. If after five attempts the terminal message is unsuccessful, InstaMed assigns a posting error workflow status. If InstaMed does not receive or has an issue receiving a Status for a Webhook HTTP post, the post will timeout for 20 seconds, and then retry. After two attempts the post will fail.



In order to secure a webhook end point, it is recommended that the following InstaMed IP addresses be whitelisted:


Authentication is an optional security method. There are three main options:

  1. Certificate-based (public key) authentication: InstaMed can use Certificate Based Mutual Authentication (Mutual SSL Authentication) to initiate the webhook with the customer’s server.  Certificate authentication can be added to either Basic Authentication or Open Authentication protocols.  
  2. Basic authentication (username/password): InstaMed can use the verified authentication version (leveraging a username and password challenge) of Basic Authentication to deliver a webhook.    
  3. Open Authorization (OAuth 2.0): InstaMed can use the recognized ID service Ping Federated 2.0 to exchange a secure token with the customer in order to deliver the webhook.  Contact an InstaMed Implementation Manager for information on using other ID services. 

InstaMed can use either Basic or Open Authentication, but not both for a specific webhook.  A certificate can be used for either Basic or Open if desired.

PLEASE NOTE: Authentication is not available for Member Payments when using the InstaMed Webhook interface

Notifications Available via Webhook

Webhook supports all messages including asynchronous messages and messages generated from the InstaMed platform, including:

Payment Triggers

  • Approved
  • Declined
  • Voided
  • Refunded
  • Returned
  • Chargeback
  • Settlement
  • Error

Payment Plan Triggers

  • Created
  • Updated

Note: The TransactionID received via the real-time notification can be used to process a void or simple refund via InstaMed Connect Web Services.

Webhook Integration Fields Table

Webhook Samples Wizard

Loading, please wait