Ankr API Integration: Where Multichain Access Breaks
Multichain access looks simple as long as an application works with one or two networks.
As soon as there are dozens of networks, a single gateway — for example, Ankr — stops being a convenient entry point and becomes the place where all failures converge: each network has its own block confirmation latency, its own rate-limit policy, and its own behavior under overload.
Node timeouts are not uniform: a request to a fast network returns instantly, while a slow one holds the connection until it drops, and the accumulated queue eats into the throughput of the other routes.
Request limits also differ from network to network — polling a dozen networks in parallel quickly exhausts the quota, some requests are silently rejected, and instead of an error the application receives an empty response.
This leads to the next class of problems — data desynchronization. One network has already confirmed a transfer, the other returns the previous state, and the resulting balance does not match what the business scenario expects.
Under peak load this looks like silent degradation: there are no explicit failures in the logs, yet the share of successful responses drops severalfold.
We break down how this is closed: by routing requests across networks, separate retry policies, and data freshness control — so that the gateway withstands growing load without manual incident triage.
What Changes After Moving to a Single Gateway to Networks
While each network is connected through its own node, the team maintains just as many independent circuits: its own address, its own limits, its own reconnection logic, and its own downtime notification.
Degradation of one node is invisible on the overall graph — it shows up as a growing share of failed requests in a specific scenario, and finding the cause starts with manually going through the nodes.
A single access layer removes this branching: calls go through one Ankr gateway with a common request format, and failover to a backup happens automatically rather than on a call from the on-call engineer.
Recovery time after a node failure is measured in seconds — the client code sends the same request, and the gateway changes the routing.
The second measurable value is the share of successful requests. With direct connections it sags on node desynchronization, a broken event-stream subscription, and exhaustion of a local limit.
This is one class of failures: the gateway itself removes the lagging node from rotation and switches the stream to an up-to-date one, so scenarios like balance accrual and transfer accounting no longer depend on the state of a specific node.
Connection maintenance becomes flat: a new network is added with an entry in the configuration rather than a separate wrapper, and monitoring looks at a single entry point instead of a dozen heterogeneous ones.
We break down which networks we move to the shared gateway right away and which we leave on their own node.
Ways to Connect to Ankr: Node, Provider, Hybrid
Network access options differ not in "quality" but in load profile: how many unique methods are called, whether event subscriptions are needed, how critical latency is, and whether it is acceptable to hand wallet addresses to an external provider.
That is why a single option for the whole project is rarely chosen — usually it is a combination for different scenarios and different networks.
| Option | When it fits | Limitations |
|---|---|---|
| Own node | Full control over data, private methods, steady and high load on one network | We take on synchronization and maintenance; rare networks are expensive to support |
| Public gateway | Quick start, reading balances and transaction history, traffic spikes | Shared rate limits, no guarantees on privacy or response time under peak |
| Hybrid scheme | We keep critical networks ourselves, the rest go through the provider | Requires routing and a single request addressing point |
| Intermediate layer with caching | Frequently repeated reads: blocks, token lists, metadata | The cache is invalidated by block number, otherwise we serve stale state |
The intermediate layer usually becomes the main working scheme: it keeps a cache of responses by block number, retries a request on failure, and switches the route between its own node and the gateway without changes to the service code.
Let us look at what this looks like at the configuration level and what checks we put in place before releasing to production.
How Implementation Proceeds: Six Stages of Engineering Work
The order of stages is not accidental: first we record how the service accesses networks today, then we build a route that will survive the failure of an individual node, and only after that do we move traffic onto it. Below is what integration with Ankr looks like, from analysis to handover to your team.
- Analysis of current connections. We inventory all calls to networks: which networks and methods are involved, how many requests each service makes, where the connection goes directly to a node and where an intermediate layer already exists.
- Fault-tolerance scheme. We determine how requests are distributed among independent access points, on which errors and timeouts failover triggers, and what the user sees while it happens.
- Keys and limits. We create separate keys per environment and service, set quotas and priorities so that background jobs do not crowd out user requests, and plan rotation.
- Testing on live traffic. Some requests go in parallel along the new route: we compare responses and latencies, look at the share of successful calls and behavior under degradation.
- Documentation and procedures. We record configurations, failover logic, and the order of actions in case of failure — with the signs by which the on-call engineer immediately understands what to do.
- Handover to the team. We go over key management, metrics, and typical failures with your engineers, and agree on the boundaries of support.
What Remains in the Project After the Work Is Delivered
The work on integration ends not with a launch into the main network, but with the handover to your team of a full set of artifacts for multichain access via Ankr.
Below is what remains in your repository and internal documentation: every item can be opened, checked, and applied without our involvement.
- Access configurations — endpoint addresses, limits and quotas for each network separately, keys in a secret store with rotation, not in code.
- Failover schemes — which route is primary, which is backup, what triggers the switch, and how the system returns back after recovery.
- Access control rules — a "role → allowed methods and networks" matrix: the test environment cannot send a transaction to the main network.
- Degradation procedure — thresholds for error rate and response time at which the service switches to read-only mode, and the conditions for exiting it.
- Instructions for the on-call shift — step-by-step scenarios for typical failures: the provider is not responding, the quota is exhausted, data diverges between networks.
- Monitoring dashboard — metrics per network and alerting rules: what the on-call engineer fixes themselves and what they escalate.
- Change procedure — how to add a new network or method without touching code, and where the history of configuration edits is recorded.
We review the artifacts together with your engineers at handover: the on-call engineer must act according to the instructions rather than look for whoever did the integration.
Case: A Wallet and Analytics Across Multiple Networks
The client is a non-custodial wallet with portfolio analytics: balances, transaction history, asset values across multiple networks.
Before implementation, each network was connected through a separate node, configurations lived in different repositories, and adding a new network took weeks.
What It Was Before
Six networks were maintained manually, each with its own response format and its own state counter.
Over a month we recorded three to four outages of 20-40 minutes each: the failure of a single connection stopped balance updates across the entire network, and failover to a backup node was done by hand.
The share of successful requests stayed around 92%, median response time was 1.8 seconds, and a third of that time was consumed by retries on timeouts.
What We Changed
We brought all networks into a single access point on Ankr: switching between networks goes by network identifier, the response format is the same, and the failure of one node is handled by retrying on a backup without the on-call engineer's involvement.
Analytics moved from six separate collectors to a single pipeline — data from all networks arrives in a common form, with only the network field differing.
What It Became
Coverage grew from six networks to fourteen, adding a new network takes days rather than weeks. Downtime per quarter is one 6-minute episode instead of a series of multi-hour outages, the share of successful requests is 99.4%, and median response time dropped to 0.4 seconds.
The load on analytics decreased: the daily report is assembled in minutes instead of hours, and support no longer maintains a table of node addresses for each network.
How Do Extended Methods Differ from Basic Calls?
A basic call answers one question: the balance of an address on a specific network, the block number, reading a single contract. It is predictable in response time and resource consumption — scenarios with one network and one metric are built on such requests.
An extended method answers a composite question: it aggregates data across several networks, adds token metadata and operation history to the balance, and returns an address's portfolio in a single response.
In Ankr such calls go through the same gateway as basic ones, so the gain is counted in the number of calls: instead of iterating through networks in a loop, the client gets a ready-made structure.
A basic call is sufficient when the task is local: one network, one address, infrequent polls. An extended method will return extra fields, take longer to assemble a response, and consume gateway resources on data nobody uses. Here the choice of method is about matching the task, not about its power.
The flip side is visible in streaming scenarios.
If thousands of wallets are constantly being updated through a single gateway, an aggregating request on every event creates load on the gateway it was not designed for: the queue grows, rate-limit rejections appear, and the cost of the request is measured in resource and quota consumption rather than the number of rows in the response.
Therefore we choose the method based on the load profile: how many networks are in one response, how often the request repeats, whether history is needed.
Then — caching of intermediate results, grouping of similar reads, and splitting streams across separate connections, so that extended methods remain where they deliver a gain.
Technical Doubts Before Starting Work
Before integration begins, the engineering team raises the same questions: what to do with already deployed nodes, how the gateway behaves under load, what happens when the limits on a key are exhausted. We address them before work starts, so that resilience decisions are not made in a hurry.
We already have our own nodes deployed — won't there be duplication?
The Ankr gateway is integrated as an additional route, not a replacement. Your own nodes remain for critical calls and writes; the gateway covers reads across networks that are not worth keeping on your own hardware.
Routing goes by call type: need full control — go direct; need breadth of coverage — go through the gateway.
How do key limits work and what happens when they are exhausted?
A limit is tied to a key and counted by the number of requests per interval, so keys are separated by service — a spike in one does not block the others. At the threshold, a queue with retries is enabled and a switch to a backup key occurs. A separate counter and alerts show the headroom in advance, not after the failure.
What happens if the gateway becomes unavailable?
Availability is checked continuously, and under degradation traffic automatically returns to your own nodes or to a second provider. The switch back takes seconds and requires no manual intervention — the backup route is laid in from the start, not after the first failure.
How do we make sure the data from the gateway is correct?
We compare gateway responses against your own nodes on a sample of addresses and blocks, and record discrepancies rather than suppressing them. For critical scenarios we add confirmation from multiple sources. If a network returns stale data, the request is retried with an explicit indication of the depth.
Let's Discuss the Task and Come Back with a Plan and Estimate
Describe the task in free form: which networks are needed, which calls to nodes the application makes and in what mode. That is enough for us to come back with a scope estimate and a work plan — without generic talk about "multichain" and "reliability".
What is useful to attach right away:
- A list of networks and priority: where you launch first, where in the second wave.
- Which methods are needed: reading balances and logs, sending transactions, event subscriptions.
- Load profile: peak requests per second, daily volume, seasonal spikes.
- Requirements for availability and block history depth, whether an archive node is needed.
- What is already in use: your own nodes, other access sources, caching and queues.
- Who accepts the result and by what date the working environment is needed.
In response we will send a work scheme and a staged implementation plan: obtaining access and verifying keys, routing requests between networks, fault tolerance with failover when a source fails, limits and monitoring.
The scheme will show where Ankr API integration covers the task entirely and where your own node or an intermediate layer is needed.
As a separate item we will attach a list of questions that must be closed before the start — usually these are exactly what determine the timeline. Let's discuss the task: name a convenient communication channel, and we will come back with an estimate and a plan.