Integrate using AI

Use the sources below with your coding agent to build an Account API integration.

AI-readable documentation

Source	Use it for
Account API llms.txt	Finding guides, references and available versions.
Markdown pages	Reading guides and examples. Use View Markdown or append `.md` to a documentation page URL.
OpenAPI contracts	Versioned operations and request/response schemas.

Markdown is generated from the same sources as this site. Give your agent the relevant links; llms.txt is not automatically read by every tool. If it cannot fetch a page, paste the Markdown instead.

Describe one feature at a time

Include your feature goal and application constraints. For example:

Add Account API balance viewing to our admin dashboard. Follow our existing backend client, authorization and UI patterns, and include local tests.

For larger integrations, work incrementally through discovery, deposits, withdrawal confirmation and webhook processing.

Optional integration prompt

Copy the prompt into your coding agent with your repository open. Add your feature goal; the prompt supplies documentation links and Account API guidance.

Account API integration

Add your feature goal when you paste this into your coding agent.

Help me integrate the Axiym Account API into the application in this repository.

Implement the feature I describe alongside this prompt. If I have not provided a feature goal, ask what I want to build before choosing the scope. Account API capabilities include viewing accounts and balances, selecting registered address book entries, retrieving deposit instructions and tracking deposits, creating and reviewing withdrawals, explicit confirmation, and tracking outcomes. Implement only the capabilities needed for my requested feature, using the application's existing architecture and conventions.

## Start with the application

Inspect the repository's instructions, language, framework, HTTP client, configuration, authentication and authorization, persistence, background jobs, and tests. Find any existing Axiym integration before adding another one. Reuse the project's established components and libraries.

Explain where the integration will fit and then implement it. Ask focused questions only when a missing decision materially changes the implementation. If no application repository is available, ask which project to use before creating a new application. If this is a backend-only project, implement the appropriate service/API interfaces and document how a caller supplies the review and confirmation decision.

## Read the Axiym sources

Target Account API 0.3.0 and event reference 0.2.0. These versions were selected when this prompt was copied. Use the matching contracts and verify that the guides still describe those versions before implementing. If a linked current guide has moved to a newer version, flag the mismatch and establish the intended version rather than silently mixing contracts.

Start with:
- Documentation index: {{DOCS_ORIGIN}}/account-api/llms.txt
- Quickstart and integration sequence: {{DOCS_ORIGIN}}/account-api/integration-guide/quick-start.md
- Access and environments: {{DOCS_ORIGIN}}/account-api/integration-guide/access-setup.md
- Sandbox setup and validation: {{DOCS_ORIGIN}}/account-api/integration-guide/sandbox-testing.md
- API contract: {{DOCS_ORIGIN}}/openapi/account-api/0.3.0.yaml
- Event contract: {{DOCS_ORIGIN}}/openapi/account-api/events/0.2.0.yaml

Read the relevant implementation guides and fundamentals before writing the corresponding code:
- Authentication: {{DOCS_ORIGIN}}/account-api/integration-guide/fundamentals/authentication.md
- Idempotency: {{DOCS_ORIGIN}}/account-api/integration-guide/fundamentals/idempotency.md
- Error handling and retries: {{DOCS_ORIGIN}}/account-api/integration-guide/fundamentals/error-handling-and-retries.md
- Pagination: {{DOCS_ORIGIN}}/account-api/integration-guide/fundamentals/pagination-and-query-parameters.md
- Deposits: {{DOCS_ORIGIN}}/account-api/integration-guide/deposit-funds.md
- Withdrawal creation and confirmation: {{DOCS_ORIGIN}}/account-api/integration-guide/create-a-withdrawal.md
- Withdrawal tracking: {{DOCS_ORIGIN}}/account-api/integration-guide/track-a-withdrawal.md
- Reconciliation: {{DOCS_ORIGIN}}/account-api/integration-guide/reconcile-activity.md
- Webhook registration: {{DOCS_ORIGIN}}/account-api/webhooks/registration-management.md
- Webhook signature verification: {{DOCS_ORIGIN}}/account-api/webhooks/verifying-signatures.md
- Webhook processing and recovery: {{DOCS_ORIGIN}}/account-api/webhooks/overview.md

Use these sources for endpoints, request and response shapes, scopes, status values, signature verification, retry rules, and examples. Follow linked operation and schema references when you need field details. If documentation cannot be retrieved or sources conflict, identify the specific gap and ask for the missing information. Do not invent endpoints, an Axiym SDK, or undocumented behavior.

## Implement the requested functionality

Apply the following guidance where it is relevant to the requested feature. Work in manageable steps and do not add unrelated API capabilities. For example, a balance-viewing feature does not require withdrawal creation or webhook registration.

1. Add a server-side Axiym client using the existing HTTP stack. Derive the sandbox base URL and authentication flow from the documentation. Load credentials from the project's configuration or secret store, keep tokens server-side, and avoid logging credentials or sensitive payloads. Add example configuration with empty secret values.

2. Add account and address book discovery, including documented pagination. Preserve the application's authorization boundaries when associating Axiym accounts, address book entries, deposits and withdrawals with its users or organization. Guide the caller through prerequisites documented for account and address book entry selection. For deposits, use the account's documented deposit instructions for its rail and network; only ACTIVE address book entries may fund deposits.

3. Add withdrawal creation and a review of the returned instruction and commercial details. Persist the identifiers and state needed for tracking and recovery. Keep confirmation as a separate explicit decision through the application's appropriate UI or API. Do not automatically confirm as a side effect of creating a withdrawal.

4. Apply documented idempotency and error handling. Keep the key for a logical operation stable across its retries and distinguish creation from confirmation. Handle ambiguous outcomes without accidentally creating or executing a second withdrawal. Represent monetary values without introducing floating-point rounding errors.

5. Add deposit and withdrawal tracking and reconciliation using the documented API and events. Distinguish an accepted request from a completed withdrawal, and a detected deposit from a credited one. Support the documented outcomes and use authoritative retrieval when needed to recover from missed or out-of-order notifications.

6. Implement the webhook receiver using the exact signature-verification procedure in Axiym's guide, including its required handling of raw request bodies and verification keys. Verify before processing, deduplicate using the documented event identifier, and fit durable processing into the existing application's architecture. Provide subscription setup instructions or an explicitly invoked setup command.

## Verify and hand over

Use mocked API responses and synthetic event fixtures for automated tests. Cover the behavior relevant to this implementation: authentication failure, pagination, invalid account or destination selection, creation without automatic confirmation, idempotent retries after timeouts, unsuccessful withdrawal outcomes, invalid webhook signatures, duplicate or out-of-order notifications, and reconciliation. Derive fixtures from the selected contracts and clearly label simulated responses.

Run the project's relevant checks and fix failures caused by your changes. Code generation and local testing should not require real credentials. Leave live API calls, webhook registration, deployment and real withdrawals for separately requested setup or validation.

Finish with the changed files, how to configure and run the integration, the checks you actually ran, and anything still missing. Clearly distinguish passing local tests from a verified sandbox integration. List the Axiym provisioning and application-specific decisions still needed before sandbox testing or production use.

Preview the full prompt before copying. Documentation links and versions are filled in automatically.

Review and validate

Passing local tests does not verify an Axiym integration. Use the quickstart and sandbox testing guide to validate your selected flows with provisioned access.

AI-readable documentation

Describe one feature at a time

Optional integration prompt

Review and validate

On this page