Speak to the team
Developers

Developers and agents

Everything public on platformd.io can be read programmatically. This page is the reference for developers and AI agents.

One thing to state plainly first: PlatformD is not live. There is no public transactional API and no self-service sandbox on platformd.io. PlatformD is an entrant in the joint Bank of England and FCA Digital Securities Sandbox, and live issuance of digital securities begins once the Bank of England confirms the next sandbox gate, targeted for early 2027. Two things are available today: machine-readable access to this site (below), and a read-and-integration path to the Principal Tokens issued on Dchain, over standard EVM JSON-RPC and an event indexer, described under Principal Tokens on Dchain below. Do not infer pricing, yield or volume figures: none are published, and any platform data shown publicly is simulated, for demonstration.

Agents on PlatformD

PlatformD is built so that the AI agents inside a finance team's systems can drive the invoice lifecycle without a person logging in to a portal. The agent interface is a Model Context Protocol (MCP) server in front of the platform API. It is in early access with design partners; write to info@platformd.io.

Who the agent acts for

  • A person, through their assistant. A finance user at a supplier or buyer connects PlatformD to their assistant and the agent acts as that user, with that user's roles. OAuth 2.1 authorisation code with PKCE; no new credential model.
  • A platform, for many companies. An AP, AR or treasury platform integrates once and acts for each of its customers as a distinct organisation on PlatformD, through an integration identity the customer's legal representative has authorised. Every action is attributable to the platform and the organisation.
  • An agent with its own identity (roadmap). The legal representative issues a verifiable credential to the agent stating what it may do for the organisation; the credential is checked on every action. See Agentlemen's Agreement: When AI Agents Need Identity and Delegation.

Across all three models, PlatformD follows open standards rather than inventing its own: OAuth 2.1 for user authorisation, LEI and vLEI for organisational identity, x401 for proving credentials over HTTP, and emerging Know Your Agent (KYA) standards for verifying what an agent is and who it acts for.

What an agent can do

Tools are workflow-shaped rather than one-to-one with API routes, and every mutating call returns the entity, its lifecycle stage and the next actions available.

  • Accounts receivable (supplier): find the buyer organisation, create and submit an invoice, track its progress from draft to notarised, listed, matched, executed and paid, sign the assignment deed within the organisation's mandate, and read the quote that cleared.
  • Accounts payable (buyer): list payables, confirm an invoice (with an updated due date where terms are being negotiated), sign the acknowledgement within the mandate, and propose payment at maturity.
  • Treasury and investors: read orderbooks and quotes; investor-scoped agents can place buy orders.

What stays with a person

Four steps are deliberately human: activating or extending the signing mandate (once, by the legal representative), linking a custodian account, confirming a payment at the custodian, and PlatformD's own approval of a buyer or investor organisation. The agent interface returns these as handoffs – a URL, who must act, and how the agent knows it is done – rather than pretending to complete them.

Machine-readable resources

  • Site overview and agent guidance: /llms.txt. Start here. It explains what PlatformD is, when an agent should use this site, and how to read it.
  • OpenAPI description of the public surface: /openapi.json. An OpenAPI 3.1 document describing every public machine-readable endpoint, including the error format.
  • Sitemap: /sitemap.xml. Every indexable page with last-modified dates.
  • Insights post metadata: /insights/chunks/1.json. Paginated JSON metadata (title, description, date, author, tags) for the Insights articles.

Markdown content negotiation

The homepage, the Insights index, every Insights post and this page are served as clean markdown when a request prefers it:

curl -H "Accept: text/markdown" https://platformd.io/

Markdown responses carry Content-Type: text/markdown; charset=utf-8 and Vary: Accept. The same documents are also addressable directly, without negotiation:

  • /md/home: the homepage
  • /md/insights: the Insights index
  • /md/developers: this page
  • /md/post/{slug}: any Insights post

Structured errors

Machine-facing paths return JSON errors with a code, a message and a resolution hint:

{
  "error": {
    "status": 404,
    "code": "not_found",
    "message": "No resource exists at this path.",
    "hint": "Available resources are listed at https://platformd.io/openapi.json."
  }
}

Requests under /api/ return this format today, because no public transactional API exists yet. Nonexistent pages return a real HTTP 404, with a markdown body when the request prefers text/markdown.

Principal Tokens on Dchain

A Principal Token (PT) is the digital security PlatformD issues on Dchain, a proof-of-stake, EVM-compatible Layer 1. Each PT is an ERC-20. Because Dchain speaks JSON-RPC and works with standard EVM tooling, integration is a matter of adding a network; no bespoke client is required.

PTs are created in the depository module on Dchain by PlatformD as the issuer. They follow the Single Token Representation standard (STR v2, the Cosmos EVM ERC-20 precompile): there is no difference in the ERC-20 interface they support. totalSupply, balanceOf, allowance, transfer, approve and transferFrom, together with the name, symbol and decimals metadata methods, all behave as standard.

  • One invoice equals one PT equals one contract address equals one ISIN.
  • Transfer restrictions are updated by the issuer of the digital securities. At the current phase, PTs are not transferable.
  • Issuance is native rather than a token referencing a register held elsewhere, so a transfer and the update to the register of title are the same event.
  • PTs are burnt at maturity. This action is initiated by the issuer and executed on Dchain; no surrender action is required by PT holders or their custodians.
  • Securities stay on Dchain and are not bridged or mirrored. Securities are issued, maintained, recorded and surrendered on Dchain. Cashleg settlement can be on a separate environment, orchestrated by the issuer.
  • Each digital security has its own deterministic contract address: one per security, and in the first instance one per invoice. The issuer manages holder eligibility through verifiable credentials, once per holder, so there is no need to approve each address individually. Each invoice's details and its ISIN are delivered by feed.

Eligibility to hold or transact a PT is proven with verifiable credentials and enforced on-chain, so standard EVM tooling keeps working while compliance is verified at the chain level. See the Verifiable Credential Verification specification.

Integration

Platform access

Institutional participants interested in the non-transactional pilot, and partners who want early access to the platform API when it opens, can write to info@platformd.io. Any platform data shown publicly is simulated, for demonstration.