Skip to main content
AMLOK Sandbox includes six fictional businesses and 30 executable scenarios. The businesses supply recognizable test identities and source information. Scenarios control the condition you want to test and the illustrative policy used for that run.

​
The six businesses

Each business includes synthetic bank, accounting, payments, commerce and verification information; normalized source records and provenance; a PDF financial statement; consent and connections; lending-product and policy versions; and an Origination. Completed assessments include results, evidence, exports and funded monitoring. Cases that need action retain the requirement or error to help you build recovery flows. The sample history covers twelve monthly periods. It is an illustrative dataset, not complete daily coverage or a production-volume dataset. Billing examples use CAD, including the US businesses.

​
Run and inspect a scenario

  1. Open Dev Tools > Sandbox scenarios.
  2. Select the scenario category, scenario and fictional business.
  3. Review Expected result before you run it.
  4. Choose Run scenario, or execute the provided request from your backend.
  5. Open Run history to inspect requests, responses, assertions and generated resource IDs.
  6. Retrieve those records through their normal API endpoints or open them in the console.
The same business can produce different outcomes when you choose different scenarios. For example, healthy uses a passing test policy, while outside_policy uses a failing threshold. These are test assessments, not decisions about actual businesses.
Scenario completion and business outcomes are different. A scenario can complete successfully because it correctly produced a failed underwriting, a declined payment or a missing-document requirement. A failed scenario means a step or expected check did not finish as intended.

​
What to cover in your integration

The API scenario guide lists all scenario IDs and expected results. Use the catalog endpoint to discover the current version, businesses and scenarios programmatically.

​
Test monitoring events and webhook delivery

Sample preparation records events without sending webhooks. Read them under Dev Tools > Deliveries & events or through GET /v1/events. An event marked Recorded is not proof that an HTTP request reached your application. To exercise your receiver, configure an enabled Sandbox endpoint, select it for a run and explicitly enable delivery. Webhook scenarios require the appropriate event scopes and subscriptions. Sandbox delivery sends real HTTP requests to that test endpoint, even though the payloads are fictional. Keep the receiver separate from production actions. Inspect delivery history and your receiver’s logs to verify arrival and attempts. Duplicate delivery retains the event ID; retries and concurrent delivery can change arrival order. You can return 503 and then 2xx from your receiver to exercise the retry path. See webhook testing details. Monitoring scenarios let you create a deterioration event, restore the fixture and resolve the prior alert. Evaluate monitoring now evaluates a run-owned active monitor. It does not advance server time or change billing periods.

​
Repeat without losing your history

Repeat with fresh records creates a new run and new linked records. It preserves previous results, logs and immutable ledger entries. Keep run IDs in your tests, and use new idempotency keys for new executions. Reuse a key only to retry the same intended command. For request bodies, permissions and automated execution, use the API scenario guide, runnable client and Data Lookup in the console.