# 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:

```bash
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:

```bash
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](https://trust.myaza.co/documentation/monitoring-events/markdown). 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](https://trust.myaza.co/documentation/wallet-screening/markdown).