How Decimal Integrated DeFi Lending With One API
Decimal is a no-code automation platform for Web3 - drag, drop, and let a workflow run on autopilot. To put lending markets on that canvas, it could have written an adapter per protocol per chain. Instead it integrated the 1delta API. Their report: it was easy, and it saved a lot of time.
Written by
1delta
Insight
Jul 13, 2026
4 min read
At a glance
Partner: Decimal, a no-code Web3 automation platform with 100+ integrations across Ethereum, Arbitrum, Polygon, Base, and other networks.
Challenge: Add lending markets to a drag-and-drop canvas without building and continuously maintaining a separate adapter for every protocol and chain.
Approach: Integrate the 1delta API as a single workflow node, providing one normalized REST interface across 500+ lending markets.
Result: One integration gave Decimal access to all lenders supported by 1delta across the seven chains currently available on its platform, replacing dozens of separate protocol-and-chain integrations and their ongoing maintenance.
Timeframe: 10–14 days of development, followed by two weeks of testing.
The challenge
Decimal's product is a visual workflow builder: a non-developer wires a trigger to a chain of actions - a price alert, a recurring swap, a treasury rebalance - and lets it run, with no Solidity and no backend of their own. The platform's value is the breadth of blocks on that canvas.
Lending is where that breadth gets expensive. "Move my idle USDC to the best deposit rate" sounds like one workflow step. Underneath it's a fragmentation problem: dozens of lenders, each with its own contracts, its own rate encoding, and its own definition of a position - multiplied by every chain. To put lending on a drag-and-drop canvas, Decimal needed all of that to collapse into one clean building block a non-developer could drop in and trust.
The real obstacle was maintenance, not the first version. Hand-rolling lenders is never done: every protocol becomes a node to document and keep alive as those protocols ship breaking changes - and the moment one does (Aave's V3.2 re-encoding of eModes mid-life is a real example), every workflow built on the old shape silently breaks. For a platform whose promise is "set it and forget it," a data layer that quietly drifts is the worst kind of liability.
The approach
Decimal integrated the 1delta API as that single building block. From the platform's side it's one normalized surface over plain HTTPS with one x-api-key header - no nodes to run, no ABIs to track. Two endpoint families cover almost everything a lending workflow needs:
Endpoint | What it returns |
|---|---|
| Every market on a chain - |
| A wallet's positions across every indexed lender - per-token deposits and debt in USD, plus a per-lender health factor |
The decisive property: every record comes back in the same shape, whichever protocol it came from. An Aave pool, a Compound V3 Comet market, a Morpho Blue market, and a Silo vault all surface as the same pool object and the same position object. Even three generations of the same protocol are normalized into one consistent schema, as shown in our article on unifying Aave. So a workflow node can render a rate or read a health factor without a single line that branches on "which protocol is this."
Two properties of that surface directly answer the challenge:
The hard parts live behind the API. Encoding
eth_calls across a dozen ABIs, decoding fixed-point rate formats, scaling raw balances by token decimals, fetching oracle prices for USD values - none of it landed in Decimal's codebase. That is why integrating was easy: parse one pool object and you've parsed them all, and a normalized REST response (inputs → request → typed outputs) already is the shape of a no-code block. In Decimal's words, "the documentation got us up and running quickly."Maintenance is upstream. When a protocol ships a breaking change, the normalization absorbs it on the API side; the node and the workflows on top of it don't move. The standing liability that made the build-it-yourself path expensive simply isn't Decimal's to carry - which is the bulk of the time saved.
The results
Decimal summed up the integration in its own words:
The developer experience with 1delta was excellent. The documentation got us up and running quickly, but what really stood out was the team's willingness to collaborate. They helped us validate our integration during testing, were responsive whenever we ran into edge cases, and even accommodated changes to the output structure to better align with Decimal's automation engine. It's rare to see that level of technical support from an infrastructure team.
— Abhijat, CEO & Founder, Decimal
Concretely, that breaks down into the work that didn't have to be built. Each row represents work that a from-scratch integration requires upfront and continues to require over time.
Work the API absorbs | Building it yourself |
|---|---|
Protocol adapters | A bespoke integration per lender, then again per chain |
Rate normalizationu | Converting each protocol's fixed-point rate encoding into one comparable APR |
Amount scaling | Scaling raw balances by token decimals and converting them into USD values |
Positions & health | Re-deriving each lender's account data and health-factor definition into one shape |
Ongoing maintenance | Tracking breaking changes - like Aave V3.2 re-encoding eModes mid-life - so workflows don't silently break |
That last row is the one that compounds. A hand-rolled integration is a standing liability that grows with every protocol and every upgrade; a normalized dependency is kept current upstream, so the next supported chain or lender can become available without Decimal building another protocol-specific adapter.
The user-facing result is that a lending strategy spanning multiple lenders is now a handful of draggable blocks. A "park idle stablecoins at the best rate" workflow reads end to end like this:
The read block is the only one that touches DeFi data, and it speaks to one API. The condition compares APYs that are already in the same unit; the action moves funds to the winning marketUid without caring whether it's an Aave market on Base or a Morpho market on Arbitrum. What would otherwise take months of adapter development shows up as one reusable node with a dropdown.
Why it worked
Decimal’s value is the canvas: the triggers, conditions, no-code ergonomics, and multi-chain execution. Normalized lending data across multiple protocols is essential underneath that, but it is not where Decimal wins or loses. It is undifferentiated infrastructure that every product needs in essentially the same form.
It helped that the data layer came with a team, not just an endpoint. 1delta "helped us validate our integration during testing, were responsive whenever we ran into edge cases, and even accommodated changes to the output structure to better align with Decimal's automation engine" - the kind of hands-on support that turns a dependency into a partnership. As Decimal put it, "it's rare to see that level of technical support from an infrastructure team."
That is the transferable lesson. If lending data is necessary for your product but not part of your competitive advantage, a normalized API removes both the initial integration work and the maintenance burden that follows. The immediate benefit is one consistent schema and one authentication layer. The longer-term benefit is every adapter, rate conversion, and breaking protocol change that never reaches your backlog.
Where to go next
Decimal: Explore the no-code Web3 automation platform featured in this case study.
API reference: Review the
/v1/data/lending/*endpoints andx-api-keysetup used by Decimal. Start with/lending/pools.1delta docs: Explore supported lenders, network coverage, and the rest of the lending API documentation.
