Test your integration

Test in your product's demo environment with the credentials from your Snapdocs setup (hosts here). Build a test plan per workflow, and release the integration in phases as each workflow's plan passes rather than holding everything for one launch.

Cover the happy path and the edge cases your transactions actually vary on. For closings that means loan type, closing type, single and multi-borrower loans, POA and trusts, and HELOCs; other products vary on their own axes, and their guides call out what to exercise.

Transactions move when parties act

A transaction does not advance on API calls alone. Real closings move forward when people do things: a signer opens the email and eSigns, a settlement agent downloads the wet-sign package and uploads signed scans, a notary completes the appointment. Your integration sees each of those as an inbound webhook — and in the demo environment, nobody performs them unless you do. Manual interactions may be required to move a transaction forward; a test that stalls is usually waiting on a party, not on your code.

For an eClose closing:

To generate	Someone must	In demo, you
Document and processing events	upload and submit the closing package	already do this — it's your API calls
Preview and eSign events	the signer reviews and eSigns from their email	open the signer's inbox and act as them
Scanback / signed-document events	the settlement agent downloads, prints, and uploads signed documents	log in as the settlement agent and do the work
Completion events	the closing reaches done, or is completed via Complete Closing	complete it yourself once signing is finished

Post Close QC behaves the same way: a package sits in review until its loan_data_requested and documents_requested events are answered.

Act as the other parties

Two setups make the role-playing above possible:

The settlement experience. Work with your Snapdocs contacts to set up a settlement office and company linked to email addresses you control. Assign those addresses as the settlement agent when you create test transactions, then log in and do the work the real agent would: download the wet-sign package, upload signed documents.

The signer experience. Use any out-of-the-box email address you have access to as the signer. Gmail's plus addressing gives you a unique address per transaction with a single inbox. Open the emails, preview, and eSign as the signer would.

Receive webhooks locally

You need a public HTTPS endpoint to receive events. For local development, run a stub server and tunnel to it.

Install json-server (requires Node.js):

npm install -g json-server

Create a db.json to store incoming messages:

{
  "events": []
}

Start the server in the same folder:

json-server --id event_id --watch db.json --port 3456

This serves a REST API at http://localhost:3456/events. Expose it publicly with ngrok:

ngrok http 3456

ngrok prints an external URL such as https://f9a1-34-124-93-13.ngrok.io. Append /events and use that as the webhook URL when you create a subscription. Events now land in db.json where you can inspect them.

Walk a product workflow

Each product's guides carry the concrete walkthroughs. For eClose, work through the Postman collection, Set Up Testing, Create A Hybrid Closing, and Successful Testing in order.

When your test plans pass, move on to certification and go-live.