Quickstart

This guide helps you send a first Travel Rule message in the Sandbox. It uses an outgoing transfer to another VASP as the example. If you are new to the platform, the Introduction explains what CryptoSwift offers before you start coding.

In your actual transfer flow, first determine whether the relevant wallet is custodial or self-hosted. Your VASP can use its own process or optional Wallet Intelligence (KYW). A custodial counterparty leads to Travel Rule messaging; a customer-controlled self-hosted wallet leads to your wallet verification policy. If the type is unknown, follow your review process before choosing a path.

1. Sign up in the Sandbox and verify your email.
2. Open Settings in the Sandbox Client Dashboard.
3. Copy your Sandbox API key. Keep it in your backend or a secrets manager.

When you need to rotate credentials or create an additional key, follow Manage API keys.

Use your Sandbox key for this test request. The wallet address and beneficiary name below are test values, not required values for your integration. The destination address and Alice Audit are a matching pair from our predefined Sandbox counterparty wallets. We use this pair so the Sandbox simulator returns a predictable DELIVERED then CONFIRMED result. For other transactions, use the destination wallet and beneficiary details for that transaction. The predefined list is only for repeatable Sandbox tests.

API_KEY='<YOUR_SANDBOX_API_KEY>'

curl --request POST 'https://api-dev.cryptoswift.eu/transactions' \
  --header "x-api-key: $API_KEY" \
  --header 'Content-Type: application/json' \
  --data '{
    "asset": "ETH",
    "amount": 0.01,
    "blockchainInfo": {
      "blockchain": "Ethereum",
      "transactionHash": "0x4564d3be6c3a7bd2f5e1947846318f03a34c66fc5b912e326b252a890514e3ab",
      "origin": "0x1234567890abcdef1234567890abcdef12345678",
      "destination": "0x114F04922ceE0b890Ececac489e6f6Ed307BCADF",
      "destinationType": "CUSTODIAL"
    },
    "originator": {
      "type": "NATURAL",
      "name": "Test Originator",
      "accountNumber": "test-customer-123",
      "address": "1 Test Street, Tallinn",
      "country": "EE"
    },
    "beneficiary": {
      "type": "NATURAL",
      "name": "Alice Audit",
      "accountNumber": "test-beneficiary-456"
    }
  }'

Expected Sandbox result: the API returns a transaction record with an id. Save that ID to reconcile later updates. For this predefined destination and matching beneficiary name, the Sandbox scenario is designed to produce DELIVERED followed by a CONFIRMED update. If the result differs, check that the destination, asset, blockchain, and beneficiary name match the Sandbox table.

The test request includes a hash, as a post-transaction flow request does; it does not broadcast an on-chain transfer. In a live post-transaction flow, create the message as the transfer is broadcast and coordinate dispatch under your applicable timing requirements. If your VASP needs a decision before broadcasting, use the pre-transaction flow. The Travel Rule data model and Sandbox API Reference provide field details. You can also generate a backend SDK.

A production integration must handle incoming messages and later status changes. For testing, register your backend HTTPS webhook URL in the Sandbox dashboard or through PATCH /tenant/me with Sandbox credentials. Then verify webhook signatures and process notifications by transaction id.

Before going live, register and test the webhook URL separately in Production through the Production dashboard or API. The Sandbox webhook setting does not carry over. See the webhook guide for delivery and recovery behavior.

If your VASP receives deposits, add and confirm a few test wallets in the Sandbox before testing incoming messages. Maintain your complete real custodial wallet inventory in Production before live incoming transfers. The inventory helps CryptoSwift match messages to your VASP; it is separate from a customer wallet you might classify with KYW or verify as self-hosted. Then test an incoming Sandbox scenario and implement incoming responses.

If the wallet-type decision points to a customer-controlled self-hosted wallet, apply your VASP's policy for ownership evidence. CryptoSwift offers a hosted or embedded widget and a custom API integration. You can also reuse an eligible prior verification or collect additional evidence in the same journey. Start with the verification overview to choose.

After the first successful request, use the relevant guides to complete your VASP's actual transaction flows. The Sandbox lets you validate matching, webhook handling, status changes, and verification before production onboarding.

• Outgoing Travel Rule messaging
• Incoming Travel Rule messaging
• Register and maintain your custodial wallets
• Self-hosted wallet verification
• Sandbox to production onboarding