Test Credentials

Test Truv’s APIs in sandbox using the credentials below. Pick the product you’re integrating against to see credentials, scenario coverage, sample responses, and sample reports specific to it. Universal authentication scenarios and environment behavior that apply across every product live on this page.

---

​

Pick your product

---

​

Universal login scenarios

These credentials apply to every product. Use them to test authentication flows, MFA paths, processing delays, and error handling. See the product-specific pages above for the credentials that drive the actual report data. See Task lifecycle for what each status means and how to handle it in your integration.

---

​

Confirming your test worked

Every test verification produces three signals you can check to confirm it ran end-to-end: If the test scenario you used was an error credential (e.g. error.user / login_error), look for the matching error status — not done. See Task lifecycle for the full status map.

---

​

Testing in production

Truv exposes three test providers in production environments. Search for them by name in Truv Bridge to run sandbox-quality test scenarios against your production API keys without billing impact on real applicants. Use the same test credentials documented on the product-specific pages — these providers return sandbox-quality data in your production environment.

---

​

Refresh testing

Data refreshes automatically succeed with goodlogin / goodpassword. To test a failed refresh, use goodlogin / mfa_captcha on the initial verification, then trigger a data refresh — the refresh will fail with mfa_error status.

---

​

Native reset for authentication

Truv Sandbox supports the native credential-reset workflow that providers expose for users who’ve forgotten their password. To test it:

1. In Truv Bridge, choose Forgot password (or the equivalent provider-specific link) on the login screen.
2. Enter any value in the requested fields the provider asks for (e.g. SSN, email, security question).
3. Use goodlogin / mfa to receive an MFA prompt — enter code 12345.
4. The reset completes and Bridge proceeds with the standard verification flow.

For embedded flows, borrowers may also be required to complete MFA during a data refresh. To exercise that path: use goodlogin / mfa_captcha on the original verification, then trigger a data refresh via POST /v1/orders/{original_order_id}/ — the refresh will surface an MFA prompt that completes successfully when the borrower passes a goodlogin MFA credential.

---

​

Native login via mobile SDKs

Native logins inside the iOS and Android SDKs hit a different code path than the WebView-based flow. In sandbox, native login works only against the Truv Payroll Provider test provider — every other provider’s native login is gated on production traffic. To exercise native login end-to-end with a real provider’s UI (e.g. ADP, Workday), switch to production keys and use the production test providers approach, which gives you sandbox-quality data through the real provider UX. If your test plan requires validating native-login UX against a specific provider (Workday, ADP, etc.) before going live, schedule a session via support@truv.com so we can pair on a controlled production test against that provider.

---

​

Supported companies for testing

The companies below return a valid company_mapping_id in sandbox. Use them when testing deeplink flows or the Company Mapping endpoint.

• Facebook: Workday
• Bank of America: Company with single sign on
• Kroger: Custom integration
• Fannie Mae: ADP
• Freddie Mac: Workday