Changelly API integration for cryptocurrency exchange: connection and setup

Changelly API Integration: Where Asset Exchange Breaks

Changelly API integration looks like a single button in the provider's dashboard and a few methods in the documentation.

In practice, cryptocurrency exchange in an application is a separate contour with its own state model, queues, and reconciliation, and it breaks not at launch, but after a few weeks on a live flow of orders.

The first typical failure is desynchronization of exchange operation statuses. The provider has already closed the order, but on our side it is still “processing”: the notification did not arrive, was processed twice, or arrived before the transaction got into our database.

The user sees a stuck exchange order, writes to support — and then we manually investigate what should have closed itself.

The second is the lack of idempotency during repeated event delivery: a repeat credits the asset twice or rolls back what has already been credited.

The third is manual reconciliation of operations: while balances between our database and the provider are reconciled by eye from an export, discrepancies accumulate, and orders live for days.

A separate loss is the user leaving the product.

If the exchange opens in the provider's external window, part of the audience does not return: it remains on someone else's storefront, and we lose the operation history, which we have nothing to show either in support or in reporting.

All four failures are treated at the contour level: a unified status model, idempotent processing, automatic reconciliation, and exchange within the application interface. Below we analyze how this is covered when connecting an exchange service.

What Exchange Inside the Product Provides: Speed and Retention

Exchange through an external service breaks the user journey at its most costly stage: they copy the address, leave the product, check the receipt themselves, and return only if everything went well.

Each such operation means two manual steps on the support side and a noticeable share of abandoned orders right at the confirmation stage.

Built-in cryptocurrency exchange closes the gap: the user stays in the familiar interface, and the trade route is selected automatically based on available liquidity, taking into account the pair's limits.

We build exchange as a state machine — the order goes through fixed statuses, the service itself reports the transition to a new one, and the balance is credited without human involvement and without manually reconciling statements.

The key points are idempotent processing of retries and explicit rules for partial execution: the operation is either completed or correctly returned to its original state. This is the level at which Changelly is connected.

Automation of exchange operations produces a measurable result: the share of orders closed without an operator approaches full, and support requests on the topic “where are my funds” almost disappear entirely — the status is visible in the interface before the user has time to write.

Exchange conversion grows because transitions outside are removed from the scenario, and the speed of asset withdrawal stops depending on which team member is currently online.

A separate class of failures that cannot be fixed by attentiveness also goes away: an incorrectly copied address, a lost order, a stuck transaction without tracking, manual balance adjustment.

These failures are replaced by understandable states with predictable behavior, rather than by investigating each case in correspondence.

Exchange Connection Options: Comparison of Approaches

The exchange contour is assembled in three ways, and the difference is not in interface convenience, but in who is responsible for the rate, liquidity, and operation support.

Direct exchange connection — you call the API methods yourself; a ready-made exchange block — you embed the service's module; redirection to an external service — you hand the scenario over to the platform.

Direct exchange connection is chosen when exchange is built into the process: balance top-up, payout, conversion inside the dashboard.

Here, idempotent keys, retries, and scheduled status reconciliation are critical — otherwise the user sees “processing” where the operation has long been closed.

A ready-made exchange block removes this work, but transfers the logic and part of the data to the service side.

A practical path is to start with the block, measure the share of users reaching the operation, and move to a direct connection when the scenario has stabilized; in this scheme, Changelly is a liquidity provider, not the only option.

Exchange Integration Stages: From Audit to Handover

The work proceeds sequentially: first we record how exchange is currently structured, then we design the flow and status scheme, and only then we write code and test it on real orders.

This order removes the main risk when integrating Changelly — when exchange has already been rolled out into the product, and a status discrepancy surfaces on the first large operations, when investigating them is most expensive.

1. Audit of the current exchange scenario. We look at which pairs and directions are already used, where orders are lost between stages, and which limits and wallet address checks exist now.
2. Design of the exchange and status scheme. We map our order states to the service's states, describe transition points, behavior when a payout gets stuck, and rules for cancellation and refund.
3. Configuration of currency pairs. We form the list of available directions, minimum amounts, rate mode — fixed or floating, rounding rules on input and output.
4. Implementation of the exchange contour. Order creation, status tracking, resilience to repeated requests, and a log of every transition with time and reason.
5. Testing of exchange scenarios. We run real orders: small amounts, unavailable pair, cancellation, refund, connection loss, manual investigation of stuck operations.
6. Observability. Metrics on the share of successful exchanges and time to pass through stages, alerts for stuck orders and growth in failures.
7. Handover of the integration to the team. Flow scheme, status descriptions, incident and disputed operation investigation instructions, and training of the on-call shift.

After handover, the team edits pair lists and limits itself, without contacting us: the scheme marks what is changed by configuration and what requires code changes.

Schemes, Regulations, and Access After Exchange Launch

After exchange launch, the integration does not live on its own: it is held together by regulations, access, and documentation used by support, finance, and the on-call shift.

Without this, the very first stuck order turns into a manual review of correspondence, and the exchange service keys end up in a shared chat. Below is a set of materials that remains with your team and is handed over together with the product.

• Exchange integration scheme — the order path from creation to final status: initiator, moment of rate fixation, method of obtaining status, failure points, and timeout behavior.
• Key access policy — key owner, separation of read and operation roles, rotation, storage in a secret vault, prohibition of keys in the repository, logs, and trackers.
• Order processing regulation — limits, retry rules, automatic confirmation conditions, and the threshold after which an order goes to manual review.
• Disputed order investigation regulation — what evidence is collected (exchange ID, transaction hash, service responses), response times to the client, and the escalation procedure to the provider.
• Support instructions — scripts for typical requests with diagnostic steps so that the first line can resolve statuses and limits without a developer.
• Exchange documentation — method contracts, error codes, and a mapping table of external statuses to internal ones.
• On-call runbook — switching to a backup route, pausing exchange, and re-reconciling balances.

The materials sit next to the code and are updated with the same change as the exchange logic: an outdated regulation is more dangerous than a missing one. The completeness and currency of these documents are part of acceptance, not a wish for the future.

Case Study: Exchange in the Personal Dashboard of a Payment Service

The client is a payment service with a personal dashboard where users exchanged assets via an external exchanger. Exchange orders fell into a common queue and were processed manually: an operator checked the rate, confirmed the transaction, and set the status.

At peak, this was about 400 orders per day, and roughly every fifth one got stuck without a final status — the operation notification was lost during a network failure, there was no repeated reconciliation, the user saw “processing” and went to support.

What Was Changed

The exchange contour was connected directly via the Changelly API, and the order flow was moved to an event model: the rate is fixed at the moment the order is created, the status comes both by notification and by scheduled polling — the discrepancy between them is closed by reconciliation.

Each order received an idempotent identifier, so repeated event delivery does not create a duplicate, and the queue gained retries with increasing delay and a separate branch for investigating exceptional cases.

What Changed

The share of operations closed without an operator grew from 62% to 97%. Orders without a final status dropped to a few per month instead of a hundred per day, and the time from creation to crediting was reduced from 20–30 minutes to 2–4.

The freed-up support time went to disputed cases, and a failure on the exchanger side stopped bringing down the entire contour: the queue replays after recovery, and not a single order is lost.

Technical Questions: Limits, Statuses, and Exchange Errors

Exchange limits in Changelly are determined by the service's rules, not by our code: the minimum and maximum depend on the currency pair and the availability of the direction.

We request them before creating an order and show them to the user — an operation that would return an error anyway is simply not sent.

The exchange operation statuses are the service's own: order created, awaiting funds receipt, exchange in progress, payout, refund.

Their mapping to the states of the internal order is described by a transition table, so the status in the accounting system changes based on a confirmed event, not based on the fact that a request was sent.

We divide exchange errors into three classes: invalid parameters, temporary unavailability of the direction, and failure after funds have been received. For the first two, correction and retry are enough; for the third, a refund is initiated.

Repeated order submission is protected by a key: the same key does not create a second operation, even if the response did not arrive the first time.

Exchange logging stores the order ID, request and response, time, and final status. An incident is investigated from the logs — without correspondence with support and manual history restoration.

Can an already paid-out operation be canceled?

Exchange is irreversible after payout: a refund is issued as a separate order on the service side and is possible only before this step. Therefore, critical scenarios are checked at confirmation, not after funds are debited.

Let's Discuss the Task and Return with an Estimate and Plan

For the exchange integration estimate to be substantive rather than “by eye,” a minimum of inputs is needed. Send them in any form — diagrams, configuration exports, an engineer's notes kept manually: this is enough for the task analysis to fit into one round.

If the exchange is built on the Changelly API, we design the exchange connection for the task based on your scenarios, not on a standard wrapper.

• Current exchange contour: which services are already involved, how orders proceed, and at which step the status is lost.
• Requirements for the exchange contour: list of directions, limits, rounding rules, behavior when the provider fails.
• Access and keys: how they are issued, where they are stored, who rotates them, and whether a separate test contour is needed.
• Load profile: daily number of orders, peak spikes, share of repeated and stuck calls.
• Audit of the current exchange: call logs, incidents from recent months, known reconciliation discrepancies.
• Acceptance criteria: what we consider success — a unified order status, automation of manual steps, absence of manual edits.

As a result, you receive an exchange work plan with stages, responsibility areas, and acceptance points, as well as the composition of the exchange contour: which components we add, which we replace, and what remains as is.

Describe the task — we will return with an estimate and a short list of risks that we see in advance.

How Does Direct Exchange Differ from Redirection to an External Service?

The fork arises at the start of the project: the user exchanges an asset inside your product, or you send them to a third-party platform.

In the first case, the interface, operation history, support, and repeat requests remain with you; in the second, they go to someone else's service, and you are left with the role of a pass-through without data about the trade.

The main difference is who owns the operation status. With direct exchange, you receive state transitions from Changelly — “created,” “confirmed,” “sent,” “completed” — and you decide what to show the user and at which step to engage support.

With redirection, you see only the fact that the user left: a stuck operation turns into a request that you cannot investigate or close.

The difference in data is even more noticeable. The direct scheme leaves addresses, amounts, history, and a reason to return with you; redirection gives this to the external service, and user retention is already built on someone else's interface.

The choice of exchange scheme dictates support cost: the more assets and pairs, the more expensive it is to keep them inside.

A hybrid usually becomes the working answer — the core scenarios and statuses remain with you, rare directions go outside, and the first line of support does not grow with the number of assets.