Skip to main content

Overview

This guide walks you through creating test users in sandbox environments. Use these test endpoints to quickly set up users in various lifecycle states for testing different scenarios.
Test endpoints are only available in development and staging environments. They are disabled in production for security reasons. Always use the sandbox environment (api.sandbox.wealthyhood.com) when working with test endpoints.
All endpoints require an M2M bearer token. Test endpoints do not require the x-user-id header since they operate on test data.

Prerequisites

  • API access and M2M credentials
  • Sandbox environment access (development or staging)
  • Understanding of user lifecycle states

1) Discover available user statuses

Before creating test users, retrieve the list of available user statuses to understand what test scenarios you can set up. Available statuses for B2B test user creation:
  • INVESTED - User with investments
  • INVESTED_WITH_CASH - User with investments and cash balance
  • INVESTED_WITH_SAVINGS - User with investments and savings
Only these three statuses are available for B2B test user creation. All users created via this endpoint will have investments, and optionally cash or savings. Use GET /test/help/statuses to get all valid status values:

2) Create a test user

Create a test user with a specific status. This sets up a user account in the desired lifecycle state with all associated data (accounts, addresses, KYC operations, portfolios, etc.). Use POST /test/users to create a test user:

Response example

The response includes the created user object with populated portfolios:
  • portfolios - User portfolios
Save the id field for use in subsequent requests.

Request parameters

string
required
Email address for the test user. Must be a valid email format. Use unique emails (e.g., include a timestamp) to avoid conflicts when running tests multiple times.
string
required
User status from the available statuses. Determines what data and relationships are created with the user (e.g., portfolios, cash balances).

3) Verify user creation

Verify that the user was created successfully and check their details:

4) Clean up test users (optional)

After completing your tests, clean up test users to keep your sandbox environment organized. Use DELETE /test/users to delete a test user:

Response example

Use this endpoint to clean up test users after completing your test scenarios to keep your sandbox environment tidy.

Complete example

Here’s a complete example that discovers statuses, creates a test user, and verifies the creation:

Common use cases

Creating users for investment testing

Create users with investments for testing investment orders:

Creating users with cash for deposit testing

Create users with investments and cash for testing deposits and cash operations:

Creating users with savings

Create users with investments and savings for testing savings-related features:

Next steps

After creating a sandbox user, you can:

Troubleshooting

Invalid email format

Error: 400 - Invalid email format Solution: Ensure the email is a valid email address format (e.g., user@example.com).

Invalid status

Error: 400 - Invalid status or Status must be one of: INVESTED, INVESTED_WITH_CASH, INVESTED_WITH_SAVINGS Solution: Only three statuses are allowed for B2B test user creation: INVESTED, INVESTED_WITH_CASH, and INVESTED_WITH_SAVINGS. Use GET /test/help/statuses to retrieve the list of valid status values. Ensure the status string matches exactly (case-sensitive).

User already exists

Error: 400 - User already exists or similar Solution: Use unique email addresses for each test user. Include a timestamp or UUID in the email (e.g., test-${Date.now()}@example.com).

Endpoint not available

Error: 403 - Forbidden or endpoint returns 404 Solution: Verify you’re using the sandbox environment (api.sandbox.wealthyhood.com). Test endpoints are disabled in production.
Always use unique email addresses for test users to avoid conflicts. Consider including timestamps or UUIDs in email addresses when running tests multiple times.