On this page

Import past transactions

Use this when you already have transactions to assess. Preview validates a batch without creating transactions, screening wallets or charging you. Apply each valid row through the existing Transaction Monitoring endpoint. Crypto rows screen the counterparty wallet; fiat rows do not call the wallet provider.

Use stable, unique externalActivityId and externalTransactionId values. Register each customer first, or use an existing externalUserId. The occurredAt value is the original transaction time. Here is one complete row:

json

{"externalActivityId":"past_001","subject":{"type":"individual","externalUserId":"customer_42"},"occurredAt":"2025-01-01T00:00:00Z","transaction":{"externalTransactionId":"transfer_001","assetClass":"fiat","direction":"outbound","amount":"125.00","currency":"USD","transactionType":"bank_transfer"}}

Send up to 100 such rows in transactions to the preview endpoint:

shell

curl -X POST "https://sandbox.trust.myaza.app/api/v1/transactions/imports/preview" \
  -H "Authorization: Bearer $MYAZA_SECRET_KEY" \
  -H "Content-Type: application/json" \
  -d '{"transactions":[{"externalActivityId":"past_001","subject":{"type":"individual","externalUserId":"customer_42"},"occurredAt":"2025-01-01T00:00:00Z","transaction":{"externalTransactionId":"transfer_001","assetClass":"fiat","direction":"outbound","amount":"125.00","currency":"USD","transactionType":"bank_transfer"}}]}'

The response includes valid, count, row-level field errors, providerCalls: 0 and billableUsage: 0. The preview rejects invalid fields and duplicate IDs within the batch. It cannot prove that an ID is unused in Myaza, that a customer exists, or what a future live decision will be.

When valid is true, submit each unchanged row to POST /api/v1/transactions, sequentially. Keep the same external IDs and payload for retries. A new assessment returns 201; an exact replay returns 200. Stop on 202, 409, network failure or another error, inspect the saved result and resume with the same IDs. A preview does not reserve IDs or prices. Use a Sandbox key to test the flow first.

The server-side SDK source has transactions.previewImport(rows) and transactions.create(row). The Trust SDK package is not published yet; use HTTP until publication. Myaza operators with a Core checkout can also preview and submit a JSON Lines file through the bundled tool:

shell

pnpm import:transactions --input past-transactions.jsonl
pnpm import:transactions --input past-transactions.jsonl --apply \
  --environment sandbox --api-url https://sandbox.trust.myaza.app

The operator tool accepts at most 1,000 rows and 5 MB per file. Use --environment production and a matching live key only when the batch is ready for live assessment. Apply is sequential and stops at the first failed or uncertain response. There are no automatic retries after an uncertain provider call. Normal transaction pricing applies to newly assessed live rows; an internal wallet screen is not a second standalone customer charge. Sandbox rows are not billable.

Read each decision through Transaction Monitoring. An imported occurredAt remains historical, but the risk decision and provider evidence are assessed now. Do not present that result as the risk state that existed on the original date. For a single explicit address check, use On-Demand Wallet Screening.