AI Agent Integration
Build CryptoSwift integrations with AI coding agents.
Use this page as the agent entry point for a CryptoSwift integration. It links to relevant source guides and workflow details.
Use the OpenAPI spec for endpoint shapes and the linked integration guides for workflow sequencing. Validate everything in the Test environment before production.
Canonical resources
- OpenAPI spec: https://api.cryptoswift.eu/api-json
- Production API: https://api.cryptoswift.eu
- Test API: https://api-dev.cryptoswift.eu
- API agent manifest: https://api.cryptoswift.eu/.well-known/cryptoswift-agent.json
- Machine-readable docs index: https://dev.cryptoswift.eu/docs-index.json
Core integration flows
First determine wallet type using the VASP's own process or optional KYW. A custodial counterparty follows Travel Rule messaging; a customer-controlled self-hosted wallet follows the VASP's verification policy. An unknown result needs a review path.
If the VASP receives deposits, use a few test wallets for incoming Sandbox tests. Maintain its full real custodial wallet inventory in Production before live incoming flows.
Outgoing transactions - For custodial destinations, create outgoing Travel Rule messages and track delivery or response statuses. Start with Outgoing transactions.
Incoming transaction handling and responses - Receive incoming Travel Rule messages, reconcile them with internal records, then confirm or decline them from your backend. Start with Incoming transactions.
Webhook notifications - Register a backend endpoint, verify webhook signatures, process events idempotently, and return a 2xx response after successful handling. Start with Webhooks.
Self-hosted wallet verification - When the VASP's policy calls for ownership evidence, create verification sessions, route users through the hosted flow, widget, or API, and reconcile completion events on your backend. Start with Self-hosted wallet verification.
Recommended workflow
- Read the Overview, onboarding steps, and Test environment.
- Inspect https://dev.cryptoswift.eu/docs-index.json and the OpenAPI spec.
- Build a server-side CryptoSwift API client with environment-specific base URLs and
X-Api-Keyauthentication. - Implement the wallet-type decision using the VASP's process and optional KYW, with a fallback for unknown results.
- Implement outgoing custodial transactions using the existing Outgoing transactions guide.
- Add a few test wallets in the Sandbox for incoming tests, then maintain the VASP's real custodial inventory in Production for live incoming transactions.
- Implement webhooks using Webhooks and Webhook signatures.
- Implement self-hosted wallet verification when the VASP's policy needs it.
- Add retries, idempotency, structured error handling, and redacted operational logs.
- Test in the Sandbox. Submit onboarding materials there; use production credentials after CryptoSwift reviews and onboards the VASP.
Minimal checklist
- Test and production base URLs are configurable.
X-Api-Keyis loaded from environment variables or a secrets manager.- No CryptoSwift API key is present in frontend, mobile, or bundled client code.
- Wallet type is classified by the VASP's process or optional KYW, with an unknown-wallet fallback.
- A small test inventory is registered and confirmed in the Sandbox; the full real custodial inventory is maintained in Production before live incoming transfers.
- Outgoing Travel Rule messages can be created and reconciled.
- Incoming Travel Rule messages can be received and confirmed or declined.
- Webhook requests are verified, deduplicated, and processed idempotently.
- Wallet verification sessions can be created and completion events are handled.
- Errors, retries, and timeouts are handled without logging sensitive PII.
Security rules
- Keep
X-Api-Keyserver-side only. - Never hardcode API keys, webhook secrets, generated tokens, or customer PII in source code.
- Never expose CryptoSwift API calls that require
X-Api-Keydirectly from browser code. - Use separate credentials for the test and production APIs.
- Verify webhook signatures before trusting webhook payloads.
- Avoid logging names, addresses, national identifiers, account numbers, wallet verification tokens, and raw webhook bodies.
- Prefer redacted structured logs with transaction IDs, statuses, event types, and timestamps.
Copy-paste AI agent prompt
You are implementing a server-side CryptoSwift integration. Use these sources: - https://dev.cryptoswift.eu/docs-index.json - https://dev.cryptoswift.eu/docs/fundamentals/overview - https://dev.cryptoswift.eu/docs/fundamentals/onboarding - https://dev.cryptoswift.eu/docs/fundamentals/test-environment - https://dev.cryptoswift.eu/docs/integration-guides/getting-started - https://dev.cryptoswift.eu/docs/integration-guides/wallet-inventory - https://dev.cryptoswift.eu/docs/integration-guides/wallet-intelligence-kyw - https://dev.cryptoswift.eu/docs/integration-guides/outgoing-transactions - https://dev.cryptoswift.eu/docs/integration-guides/incoming-transactions - https://dev.cryptoswift.eu/docs/integration-guides/webhooks - https://dev.cryptoswift.eu/docs/integration-guides/self-hosted-wallet-verification - https://api.cryptoswift.eu/api-json Implement the integration in this order: 1. Configure test and production base URLs, defaulting to the test API first. 2. Load the CryptoSwift API key from server-side environment variables or a secrets manager. 3. Add a backend API client that sends `X-Api-Key` only from server-side code. 4. Implement the VASP's wallet-type decision using its own process or optional KYW. Handle UNKNOWN with its review policy. 5. Register and confirm a few test wallets in the Sandbox for incoming tests. Maintain the full real custodial inventory in Production before live incoming transfers. 6. Implement outgoing Travel Rule messaging for custodial counterparties and incoming responses where applicable. 7. Implement webhook receipt, signature verification, idempotency, and retries. 8. Implement self-hosted wallet verification when the VASP's policy requires it. 9. Test in the Sandbox and submit onboarding materials there before using production credentials. Constraints: - Do not hardcode API keys, webhook secrets, generated tokens, credentials, or real customer data. - Do not expose `X-Api-Key` in frontend, mobile, static, or bundled client code. - Do not log sensitive PII, raw API keys, webhook secrets, wallet verification tokens, or raw request bodies containing personal data. - Do not duplicate the existing CryptoSwift guides in project docs; link to the provided docs URLs instead. - Use the OpenAPI spec for endpoint schemas and the existing docs for workflow sequencing.