> ## Documentation Index
> Fetch the complete documentation index at: https://docs.truv.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Test Credentials
> Start here — pick your product, then use the universal login scenarios and sandbox environment behavior that apply across every Truv product
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.
For additional login fields used by any test credential, use **Phone:** `(111)111-1111` and **Email:** `goodlogin@domain.com`.
***
## Pick your product
VOIE and VOE — payroll credentials, pay-frequency variants, sample PDFs
VOA — financial accounts credentials, bank income source variants
DDS — allocation scenarios, switch\_deposit lifecycle, error states
PLL — setup confirmation and ongoing deduction events
Test paystubs, W-2s, 1099s, and filename-driven fraud detection scenarios
Fannie Mae D1C and Freddie Mac AIM end-to-end submission flows
***
## 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.
| Username | Password | Scenario |
| ------------ | ---------------- | ----------------------------------------------- |
| `goodlogin` | `goodpassword` | Successful login with complete data |
| `goodlogin` | `no_data` | Successful login, provider returns zero records |
| `goodlogin` | `mfa` | **MFA flow** — enter code: **12345** |
| `goodlogin` | `mfa_captcha` | **MFA captcha** — enter answer: **9M4BP** |
| `goodlogin` | `mfa_select` | **MFA flow** — verification method selection |
| `goodlogin` | `longcheck` | **Wait state** — \~30 second processing delay |
| `error.user` | `login_error` | Incorrect credentials |
| `error.user` | `mfa_error` | MFA verification failed |
| `error.user` | `account_locked` | Account locked by provider |
| `error.user` | `unavailable` | Provider under maintenance |
| `error.user` | `error` | Generic login error |
| `error.user` | `config_error` | Organization ID configuration failure |
See [Task lifecycle](/api-reference/tasks/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:
| Signal | Where to find it | What to look for |
| ----------------------------- | -------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| Webhook events | Your registered webhook endpoint | `task-status-updated` events per status transition; `order-status-updated` on terminal state (orders only) |
| Order or task status (API) | `GET /v1/orders/{id}/` for orders, or the [link status endpoint](/api-reference/links/object) for Bridge | `status: done` on the task or `status: completed` on the suborder |
| Connection record (Dashboard) | [Dashboard → Users / Orders](https://dashboard.truv.com/app/users) | The connection row appears with the expected provider, employer, and product type |
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](/api-reference/tasks/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.
| Provider | Type | Use case |
| --------------------- | -------------------------------- | ------------------------------------------------------------- |
| Truv Payroll Provider | Payroll | Test VOIE, VOE, DDS, and PLL flows |
| Truv Bank OAuth | Financial accounts (OAuth) | Test asset and transaction flows with OAuth login |
| Truv Bank non-OAuth | Financial accounts (credentials) | Test asset and transaction flows with username/password login |
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](#testing-in-production) 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](mailto: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](/api-reference/companies/company_mapping).
* **Facebook**: Workday
* **Bank of America**: Company with single sign on
* **Kroger**: Custom integration
* **Fannie Mae**: ADP
* **Freddie Mac**: Workday
In sandbox, only the companies above return a `company_mapping_id` from the Company Mapping endpoint. Production environments resolve `company_mapping_id` for the full Truv employer network. If you need a specific company mapped for sandbox testing (for example, to validate a deeplink flow into your largest customer's employer), email [support@truv.com](mailto:support@truv.com) and we'll add it to your sandbox set.