Developers

API-first wasn't a feature. It was the founding decision.

Vertalo was built API-first from the ground up — before launch, before the first client. That decision, made in 2018, is why the same platform can offer agentic tokenization and transfer agency today: an agent can only operate what an integration can reach, and everything here was built to be reached.

In production since 2018 · 200+ GraphQL operations · fronted by the Vertalo MCP Server

the decision, compounding
2018

Built API-first

Vertalo integrates with itself: our own frontend calls the same API clients call. No privileged inner interface — the API is the platform.

2023

The API Standard, published

The architecture written down: one GraphQL endpoint over a Shared Ledger — the Golden Source for private asset data.

2026

The MCP Server fronts it

Agents discover role-scoped tools over the same API. Agentic transfer agency — because the platform never needed a human at the keyboard.

Built differently

We integrated with ourselves first.

Most platforms bolt an API onto a product. Vertalo did the reverse: from day one we treated ourselves as a third party to our own Shared Ledger, and built the product on the same API we hand to clients. Every capability the platform has ever shipped arrived through that one door.

That is why the arrival of AI agents required no re-architecture. An agent is just another well-behaved integrator — and this platform has never known any other kind.

The reasoning, in long form: The Vertalo API Standard on Chain-Enabled →
The API standard

One endpoint. One Golden Source. Built to be integrated.

Single GraphQL endpoint

One strongly-typed, introspective schema. Ask for exactly the data you need in one round-trip — no stitching a dozen REST routes.

Shared Ledger · Golden Source

Purpose-built ledgers — transfer agent, ATS, blockchain — unified into one authoritative record. Every party sees only the data it is party to.

Role-based access below the API

Permissions enforced beneath the surface, uniformly — not requested politely per query.

Rolled-up calls

Multi-step workflows bundled into one request, so common operations don't become multi-trip integrations.

Create-or-get

Idempotent calls that create a record or return the existing one. Simpler, safer integration logic with less defensive code.

Webhooks & async events

React to settlement, blockchain confirmations, and position changes without polling — the backbone for agent-orchestrated workflows.

Agentic access

The API got a front door.

api.vertalo.com is now fronted by the Vertalo MCP Server. Your backend authenticates with credentials we issue, and your agent discovers role-scoped tools — issuer, broker-dealer, ATS, custodian — over the same operations, the same permissions, the same ledger.

Reads and writes, split

Read-only resources give agents live context with no write exposure. State-changing tools are separate, and scoped.

Delegation on every write

Every state-changing call records which person authorized which agent to take which action, under which role.

Human gates on regulated actions

Issuance, transfer, clawback, redemption — the calls that move the register stay behind explicit human confirmation.

The architecture

One ledger. Both kinds of assets.

The securityholder record holds traditional book-entry — digital, dematerialized — securities and tokenized holdings side by side. Same record, same transfer-agent authority. The token is a representation; the register is the truth.

Golden source

General Ledger

The singular, authoritative repository — dematerialized and tokenized positions reconciled into one record.

↑ unified from purpose-built ledgers ↑
Ledger

Transfer Agent

Holders, quantities, restrictions, issuance events.

Ledger

ATS

Trading and settlement data, party-scoped.

Ledger

Blockchain

On-chain positions and events, synced in order.

↓ represented on-chain via the Vertalo Securities Protocol ↓
EthereumTezosAptos+ adapters, not rearchitecture

If chain data is ever unavailable, the transfer-agent architecture keeps ownership records intact and operations running.

Getting started

Integrate in weeks — or point an agent at it.

STEP 1

Request sandbox access

A person reads every request. You get a tenant seeded with demo data, and credentials for your backend.

STEP 2

Choose your door

GraphQL direct — typed, introspective, documented at api.vertalo.com — or the MCP client library of your choice, from a backend you control.

STEP 3

Build against the register

Issuance, transfers, webhooks. Watch it settle in the sandbox before a line of production code — with delegation recorded on every write.

Build on the register.

Sandbox access is open — bring your integration team or your agent. Same tenant, same register, either door.