AI Agent Prompts

Implement a full server-side CryptoSwift backend integration.

Use these sources first:
- https://dev.cryptoswift.eu/docs-index.json
- https://dev.cryptoswift.eu/docs/fundamentals/test-environment
- https://dev.cryptoswift.eu/docs/integration-guides/getting-started
- 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

Build these pieces:
- Environment-specific CryptoSwift base URL configuration, defaulting to the test API.
- A server-side API client using `X-Api-Key`.
- Outgoing transaction creation and status reconciliation.
- Incoming transaction receipt, validation, and CONFIRMED or DECLINED responses.
- Webhook endpoint handling with signature verification and idempotency.
- Self-hosted wallet verification session creation and completion handling.
- Tests against the test environment before production is enabled.

Security constraints:
- Do not hardcode API keys, webhook secrets, generated tokens, or real customer data.
- Do not expose `X-Api-Key` in frontend, mobile, static, or bundled client-side code.
- Use the CryptoSwift test environment first and keep production behind explicit configuration.
- Avoid logging sensitive PII; log redacted IDs, statuses, event types, and timestamps only.

Implement CryptoSwift outgoing Travel Rule transaction support.

Use these sources first:
- https://dev.cryptoswift.eu/docs/fundamentals/test-environment
- https://dev.cryptoswift.eu/docs/integration-guides/outgoing-transactions
- https://dev.cryptoswift.eu/docs/integration-guides/webhooks
- https://api.cryptoswift.eu/api-json

Build a server-side workflow that creates outgoing Travel Rule messages, stores the returned CryptoSwift transaction ID, handles post-transaction and pre-transaction patterns where required, and reconciles status changes through webhooks or polling.

Security constraints:
- Do not hardcode API keys, webhook secrets, generated tokens, or real customer data.
- Do not expose `X-Api-Key` in frontend, mobile, static, or bundled client-side code.
- Use the CryptoSwift test environment first and keep production behind explicit configuration.
- Avoid logging sensitive PII; log redacted transaction IDs, statuses, event types, and timestamps only.

Implement CryptoSwift incoming Travel Rule transaction handling.

Use these sources first:
- https://dev.cryptoswift.eu/docs/fundamentals/test-environment
- https://dev.cryptoswift.eu/docs/integration-guides/incoming-transactions
- https://dev.cryptoswift.eu/docs/integration-guides/webhooks
- https://api.cryptoswift.eu/api-json

Build a server-side workflow that receives incoming Travel Rule messages, reconciles wallet and beneficiary data with internal records, decides whether to confirm or decline, and sends the correct backend response to CryptoSwift.

Security constraints:
- Do not hardcode API keys, webhook secrets, generated tokens, or real customer data.
- Do not expose `X-Api-Key` in frontend, mobile, static, or bundled client-side code.
- Use the CryptoSwift test environment first and keep production behind explicit configuration.
- Avoid logging sensitive PII; log redacted transaction IDs, statuses, event types, and timestamps only.

Implement CryptoSwift webhook handling.

Use these sources first:
- https://dev.cryptoswift.eu/docs/fundamentals/test-environment
- https://dev.cryptoswift.eu/docs/integration-guides/webhooks
- https://dev.cryptoswift.eu/docs/integration-guides/webhooks/signatures
- https://dev.cryptoswift.eu/docs/integration-guides/webhooks/testing-webhook-notifications
- https://api.cryptoswift.eu/api-json

Build a backend webhook endpoint that accepts CryptoSwift events, verifies signatures before processing, handles transaction and wallet verification event types, deduplicates repeated deliveries, returns 2xx only after successful processing, and records retry-safe event state.

Security constraints:
- Do not hardcode API keys, webhook secrets, generated tokens, or real customer data.
- Do not expose `X-Api-Key` in frontend, mobile, static, or bundled client-side code.
- Use the CryptoSwift test environment first and keep production behind explicit configuration.
- Avoid logging sensitive PII; log redacted event IDs, statuses, event types, and timestamps only.

Implement CryptoSwift self-hosted wallet verification.

Use these sources first:
- https://dev.cryptoswift.eu/docs/fundamentals/test-environment
- https://dev.cryptoswift.eu/docs/integration-guides/self-hosted-wallet-verification
- https://dev.cryptoswift.eu/docs/integration-guides/self-hosted-wallet-verification/api
- https://dev.cryptoswift.eu/docs/integration-guides/webhooks
- https://api.cryptoswift.eu/api-json

Build a server-side workflow that creates wallet verification sessions, passes only the required frontend-safe widget or hosted-flow data to the client, stores the wallet verification ID, and reconciles completion through webhooks or backend status checks.

Security constraints:
- Do not hardcode API keys, webhook secrets, generated tokens, or real customer data.
- Do not expose `X-Api-Key` in frontend, mobile, static, or bundled client-side code.
- Use the CryptoSwift test environment first and keep production behind explicit configuration.
- Avoid logging sensitive PII; log redacted wallet verification IDs, statuses, event types, and timestamps only.

Generate a CryptoSwift SDK from the OpenAPI spec and wire it into the backend integration.

Use these sources first:
- https://dev.cryptoswift.eu/docs/api-reference/generate-sdk
- https://dev.cryptoswift.eu/docs/fundamentals/test-environment
- https://api.cryptoswift.eu/api-json

Confirm Java is installed before running OpenAPI Generator. Generate the SDK, configure the base URL through environment-specific server-side config, add `X-Api-Key` authentication from server-side environment variables, and write a small backend smoke test against the test API.

Security constraints:
- Do not hardcode API keys, webhook secrets, generated tokens, or real customer data.
- Do not expose `X-Api-Key` in frontend, mobile, static, or bundled client-side code.
- Use the CryptoSwift test environment first and keep production behind explicit configuration.
- Avoid logging sensitive PII; log redacted IDs, statuses, event types, and timestamps only.

Review an existing CryptoSwift integration for production readiness.

Use these sources first:
- https://dev.cryptoswift.eu/docs/fundamentals/test-environment
- 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

Check that the integration has been validated in the test environment, uses environment-specific base URLs and API keys, keeps all CryptoSwift authenticated calls on the server, verifies webhook signatures, implements retries and idempotency, handles outgoing and incoming transaction statuses, handles wallet verification completion, and has redacted operational logging.

Security constraints:
- Do not hardcode API keys, webhook secrets, generated tokens, or real customer data.
- Do not expose `X-Api-Key` in frontend, mobile, static, or bundled client-side code.
- Use the CryptoSwift test environment first and require explicit approval before production configuration is used.
- Avoid logging sensitive PII; log redacted IDs, statuses, event types, and timestamps only.