Successful Testing
Snapdocs API based integrations will require thorough testing, and it includes requirements that may not be obvious to those who are not steeped in Snapdocs eClose interactions. The following are some major themes we find are not well understood when trying to test with Snapdocs APIs.
- Interacting with the closing as various user roles (borrower, settlement, lender users) through a browser and manual clicks
- Setting fields at Closings Create such that they are correctly firing events and connections in a test transaction
- Using documents that will pass Snapdocs Document processing
- Leveraging Closings Create postman calls, when the integration may not require that endpoint
This guide is going to call out a few workflows that have caused issues for some integrations, and hopefully help frame the concerns so that other details are easy for our integrators to find themselves.
Interaction Expectations
Many integration workflows require the firing of Snapdocs Webhook events, listening and processing those events to kick off integration workflows on your integration and backend. Snapdocs testing expects that you are interacting with the closing as each party in order to reliably trigger those events. Logging in as a Borrower or Settlement Agent, and performing activities like preview, esign, download the wet package, upload a PDF that pretends to be the signed completed package, etc.
Borrower
For example, the Borrower is a party who has actions that are required to make various signing events happen.
| Event Triggers | Action(s) Required |
|---|---|
| borrower.preview_available | - Proper documents were uploaded successfully. Borrower email address is valid. - Email is generated for the borrower. Test resource is able to access the Review and eSign Email pending. |
| borrower.preview_complete | - Review button in borrower email is clicked. - Tester logs in as borrower (settings are appropriate for tester to log in (i.e. US phone number, 2fa, username/pw). - Tester is logged in as consumer, scrolls through preview experience, finishes preview |
| borrower.esigning_available | - Closing created as hybrid or hybrid with eNote Preview has completed - Closing date was sent through as today (and/or * eSign constraints are loosened in the customer configuration) - Company eSign constraints are configured appropriately for testers to eSign to be available soon after preview |
| borrower.esigning_complete | Button may be available immediately after preview, depending on the date of the signing and eSign constraint settings. The actions below assume you leave Snapdocs after preview. - Review and Esign button in borrower email is clicked. - Tester logs in as borrower. - Tester eSigns the documents through the eSign experience. |
Settlement Agent
Settlement agents, Title or Escrow company users, or whatever other parties are providing the settlement signing services will interact with Snapdocs in order to process the wet documents.
| Event Triggers | Action(s) Required |
|---|---|
| - Log in as Settlement Agent - Download wet sign package | |
| document.created scanback documents | - Log in as Settlement Agent - Upload a pdf document for signed scanback (there is no requirement that it has real signatures) |
| document.created signed complete package | - Upon upload of pdf (prior step), click the appropriate button to signify you are done uploading scanbacks. The combined signed document process will kick off in the background, firing this event. |
Lender
The third primary user type is lender users, however for integration testing through Snapdocs Connect we don’t expect in-app actions to unlock webhook events. Snapdocs builds its APIs and Integrations to enable Lender Users to control their interactions and updates through the LOS systems, without manual steps in the Snapdocs applications.
Important Closings Create fields
There are various downstream actions that require that you’re passing in fields that will help your testing go smoother.
Identifiers
Your webhook listener and subsequent processor / handler methods will likely need to make determinations about what action / transaction to take on, based on the matching of a Closing Identifier to your core system.
Update your closings create API calls to include appropriate test transaction identifiers, such that webhooks will contain them as later events take place on the closing.
- file_number: often this is a readable file value, only used for display. However, this could be a value that connects transactions.
- reference_id: this is often populated with the unique identifier in the LOS system, whether that is a loan guid or a numeric file id. To mimic what is sent by an LOS integration, we recommend test transactions start with this id.
- external_identifiers array: these are values that are published in the webhook payload for every Snapdocs webhook. The values in this array may include the LOS identifier, TPS identifiers (settlement company software id), or other system identifiers. The acceptable current values for the system and field type is available on the Closings Create external identifiers object.
Create a new closing
Emails and Phone Numbers
- borrowers array - phone, email
- closing_users array - phone, email
- settlement_agents array - phone, email
- settlement_office_email
Our Snapdocs cs-demo0 environment sends emails and SMS messages to end users. Various borrower, settlement company, lender user interactions require clicking buttons that are in the email. It is important to use distinct emails per user, and use email addresses your testing team has access to. Snapdocs encourages the use of gmail based inboxes, as they have the + feature that allows unique email values to act as separate Snapdocs users, while routing everything to a single inbox.
Your cs-demo0 account may be set to our standard borrower authentication which includes the email messages and 2fa texts. However, our text policy only sends SMS messages for 2fa to US based cell numbers. If your development team is unable to reliably use a US based cell number, we strongly recommend working with your Business Development, Customer Success, or Engineering contact to configure your cs-demo0 environment for username and password borrower authentication.
Dates
Our standard cs-demo0 company setup includes a set of eSigning constraints about when eSigning can take place. Most of these rules calculate when to send emails or webhooks based on the company configured rules and the closing dates on the closing.
- Appointment_earliest_at & appointment_latest_at: for customers or transactions that allow date ranges for eSigned closing documents you can pass both of these values in. Our email sends at midnight in the timezone of the closing on the earliest date.
- Appointment_date: for customers who set a single date for the closing, our email sends at midnight on the date of the appointment.
If you are not seeing the preview or eSign borrower events you can validate if your closing date was set appropriately.
The eSign constraints are configurable for the account your key is configured for, and you can contact your Business Development, Customer Success, or Engineering contact to update the configuration to match your needs.
Documents
Snapdocs uses our document processing AI technology in our non-production and production environments, so to ensure original closing packages are split into eSign and Wet packages you must submit packages that our document processing is trained for. Work with your Business Development, Customer Successcontact at Snapdocs in order to ensure you have appropriate documents for your use case.
For example, if you want to create a Hybrid with eNote you need to ensure that your package contains at least 1 document to wet sign, 1 document to eSign, and a promissory note that matches the supported eVault forms for your configured test vault.
Standard Test Scenarios
Below are some possible differences per closing. Your integration should ensure it works well for various combinations of settings.
- Single borrower, multiple borrowers
- Signing types - wet, full eClosings, hybrid, hybrid with eNote
- Closing same day, preview today and close tomorrow
- Redraws - full, partial redraws, before any Borrower / Settlement interactions, after Settlement has downloaded, after Borrower has eSigned, with note replaced
Troubleshooting FAQ
I did not get the borrower email?
- Was the closing initiated with an email address where you have access to the inbox?
- Was the date set in the future, such that you’ll receive the email in the coming days?
- Did you create the closing, attach documents, and submit the closing to processing?
- Did you use documents that will pass Snapdocs doc processing as expected?
Why is my closing a wet closing when I submitted it as hybrid?
- Did you use a closing package that contains valid documents that will be hybrid documents?
- Can you confirm with your BD, CS, or Engineering contact at Snapdocs that there are classification preferences for your account and they include eSignable documents?
- Has your company submitted sample packages such that we have an AI model for your account?
- Are you using the Snapdocs sample documents from your BD or CS partner?
Why can’t I log in with the 2fa text code?
- Did you submit your borrower with a phone number where you have access to that device?
- Is your submitted phone number a US based phone number?
Why am I not seeing the borrower eSign events?
- Did you set the appropriate closing date to today?
- Have you signed in as the borrower to preview? Preview is what unlocks the eSign.
Updated over 1 year ago