Digital euro API and developer documentation status

Short answer

There is no public, production digital euro API that developers can sign up for. The digital euro has not been issued, and only licensed payment service providers will connect to the Eurosystem's platform. What is public is documentation: the draft scheme rulebook v0.91 with implementation specifications, and pilot back-end specifications with a YAML file, published in April 2026.

What do people mean by "digital euro API"?

The phrase is used for at least four different things, and most confusion starts there.

1. The Eurosystem's back-end APIs. The ECB calls the central platform the Digital Euro Service Platform (DESP). Its APIs are how a payment service provider (PSP) registers users, looks up aliases, settles payments and receives reports. These are documented, but only PSPs will connect to them.
2. Front-end implementation specifications. These describe what a PSP's app, an acceptance device or a merchant checkout must do so that every digital euro payment looks and behaves the same. They are requirements more than callable APIs.
3. The Eurosystem SDK. The ECB has procured a digital euro app and a software development kit (SDK) that PSPs can embed in their own banking apps. It is not a public SDK for third-party developers.
4. Market standards underneath. The ECB has chosen to reuse existing European standards for card-style contactless payments, merchant-to-acquirer messages and alias-based payments, plus the ISO 20022 data model.

Searches for a "digital euro developer API", the "ECB digital euro APIs" or a "digital euro integration API" usually mean the first or third item. If you are a merchant or a software vendor hoping to "integrate the digital euro API" into a shop, the honest answer is that you would integrate your acquirer's or payment gateway's API, which would in turn connect to the DESP. Our guide for businesses explains that business picture. This page covers the technical documentation itself. For developer roles, skills and routes into the ecosystem, see our page on digital euro developer opportunities.

DIGITAL EUR is an independent publisher and is not affiliated with the ECB or the Eurosystem. Nothing here is an official specification.

What is publicly documented, and what is not?

The table lists the technical material we found on the ECB's website on 5 November 2026. Dates are the publication dates shown by the ECB.

Just as important is what we could not find:

• No production API. There is nothing to call outside the pilot, and the pilot itself starts in the second half of 2027.
• No public sandbox or simulator. In the ECB's summary of its March 2026 workshops, technical service providers listed a technical simulator for early development and testing among the things that would help market readiness. That reads as a request, not an existing service.
• No developer portal, API keys or self-service onboarding. Access runs through contracts with the ECB and connectivity through the selected network service providers.
• No public SDK download. The SDK is a component for PSPs, and the ECB says development of components will be decided at a later stage.
• No final rulebook. Version 0.91 is a draft, and the legislation it depends on is still in negotiation. Our legislation tracker follows that.

How is the DESP back-end API organised?

The pilot back-end specifications group the central APIs into services. The table below uses the service names and example endpoint paths from the 23 April 2026 document; paths may change in later versions.

A few design choices stand out:

• REST and JSON. The document describes RESTful interfaces with JSON payloads, accompanied by a YAML file containing the API data model.
• ISO 20022 vocabulary. Data types are based on the ISO 20022 data dictionary where available. Transaction status uses the ISO external code set, so a rejected payment carries the familiar status RJCT and a reason code.
• Reused market standards. Alias lookup reuses parts of the Berlin Group's Mobile P2P Interoperability Framework, and the SEPI service reuses CPACE.
• Two directions. Settlement has a DESP API that PSPs call and a PSP API that the DESP calls, so a PSP must also expose endpoints of its own.

The draft rulebook v0.91 splits the back-end annex differently, into eight parts: introduction and exceptions management, access management and alias lookup, SEPI (NFC), risk and fraud, dispute management, data exchange, settlement, and a data dictionary. Risk and fraud and dispute management therefore appear in the rulebook draft even though they are not separate services in the pilot API table above.

Worked example: what happens when a payment call fails?

The most useful part of the specification for an engineer is the error model, because it is easy to get wrong. The steps below are our annotated reading of section 1 and section 2.3.3 of the pilot back-end document. They are an illustration, not an official integration guide.

1. The PSP sends a request with a Request-Id. Every request and response must carry a unique Request-Id in UUID form, and the response echoes it.
2. The PSP reads the HTTP code first. A 200, 201 or 202 means the request was accepted technically. A 202 means the answer will come asynchronously.
3. Then it reads the business status. A request can be technically fine and still fail on business grounds, for example insufficient funds. In that case the HTTP code is still 200 or 201, and the body carries a transaction status of RJCT with a reason code.
4. It handles functional time-outs. If processing exceeds the maximum time set in the pilot's non-functional requirements, the response carries RJCT with reason AB03 ("AbortedSettlementTimeout"), and the DESP sends a reject notification to all PSPs involved.
5. It handles technical errors separately. Malformed requests return 4xx codes, and server problems return 5xx codes, with a problem+JSON body where applicable. A missing response or an HTTP 504 counts as a technical time-out.
6. It retries safely. If the PSP repeats a request with the same Request-Id and identical business content, and the resource has not changed, the server should return the same response as before. The same Request-Id with different content is rejected with a 4xx code.

The lesson carries over to any payment integration: an HTTP success is not a payment success. Teams that already handle card or SEPA instant payment status codes will recognise the pattern. It is also the same idempotency discipline that good payment webhook handling needs, because the DESP calls PSP endpoints too, and duplicates must not create duplicate effects.

Who can actually call these APIs?

Only supervised intermediaries, and in practice only a small group for now.

• Pilot PSPs. The ECB has selected 36 PSPs licensed in the euro area for the 12-month pilot planned from the second half of 2027 (ECB pilot page). Our pilot page covers who they are and how selection worked.
• Technical service providers acting for PSPs. The ECB's pilot FAQ describes them as third parties that help a participating PSP develop, integrate or operate its services, including payment processors, software vendors and system integrators (ECB pilot FAQ).
• Network connectivity. On 30 October 2026 the ECB announced two network service providers: a grouping of Nexi Payments and Deutsche Telekom Business Solutions, and a grouping of Telefónica and Indra companies. All PSPs offering the digital euro can connect through either provider (ECB).
• Merchants reach the digital euro through an acquiring PSP, not through the DESP. In the pilot, the acquiring PSP provides the acceptance solution and integration guidance.
• Innovation platform participants work as simulated PSPs in a test environment, which is not the production DESP. See our page on the innovation platform.

The ECB's pilot FAQ adds one point that matters for planning: the main elements, including the technical interfaces to the DESP, are intended to remain stable over time, so pilot work is not expected to become a sunk cost.

Is there a digital euro SDK?

Yes on paper, but not one you can download. The ECB's contract notice describes a digital euro app plus an SDK that "helps PSPs to integrate digital euro services" into their own apps and online interfaces. The SDK is embedded in a PSP's mobile banking app as a software library and includes a client to the DESP's standard APIs. The stand-alone app is to be offered in the official Android and iOS app stores, with each user choosing a PSP on first launch (ECB contract notice).

On 2 October 2025 the ECB named Almaviva and Fabrick as first-ranked providers for the app and SDK component. The framework agreements involve no payment at this stage, and actual development will be decided later (ECB).

You may find websites that publish a "digital euro API" with mock endpoints and simulated data. They are unofficial. Check every technical claim against the ECB's own documents before you build on it.

Which standards and technical requirements sit behind the APIs?

The digital euro's technical requirements are spread across the rulebook annexes and the pilot documents, and there is no separate "digital euro rulebook API" document: the rulebook's back-end annex D2 is where the API requirements live. The standards underneath are the more stable part. The ECB announced on 24 April 2026 that it had signed agreements with three European standard setters to reuse existing open standards (ECB press release):

The ECB calls these standards "accessible to all stakeholders", and the release says CPACE can be used free of charge. Further standards could be added later. Piero Cipollone told the European Parliament on 3 June 2026 that early clarity on the standards lets private operators start building now, but that only the co-legislators can provide legal certainty that the standards will apply across the euro area (ECB speech).

How does this compare with euro payment APIs you can use today?

For most software teams, the useful work today is with the last three rows, and digital euro integrations for merchants will most likely arrive as an extension of the acquirer row. That is also where our own product sits.

What euro payment data can you work with today?

Whatever happens to the digital euro, received payments end up in an ordinary euro bank account, as our business guide explains. The data problems developers solve today will remain: importing bank transactions (whether through a bank transaction import API, an XML statement or a CSV file), normalising them and matching them to invoices. Euro payment data normalisation is unglamorous, but it decides whether matching works.

A camt.053 sample, field by field

camt.053 is the ISO 20022 end-of-day bank-to-customer statement. Below is an abridged, illustrative entry with invented values. Element names are modelled on version camt.053.001.08; the nesting of the status and party elements differs between versions, so check your bank's implementation guide.

<Ntry>
  <Amt Ccy="EUR">1250.00</Amt>
  <CdtDbtInd>CRDT</CdtDbtInd>
  <Sts><Cd>BOOK</Cd></Sts>
  <BookgDt><Dt>2026-11-03</Dt></BookgDt>
  <ValDt><Dt>2026-11-03</Dt></ValDt>
  <NtryDtls><TxDtls>
    <Refs><EndToEndId>INV-2026-0147</EndToEndId></Refs>
    <RltdPties>
      <Dbtr><Pty><Nm>Example Trading GmbH</Nm></Pty></Dbtr>
      <DbtrAcct><Id><IBAN>DE00EXAMPLE0000000000</IBAN></Id></DbtrAcct>
    </RltdPties>
    <RmtInf><Ustrd>Invoice INV-2026-0147</Ustrd></RmtInf>
  </TxDtls></NtryDtls>
</Ntry>

ISO 20022 bank transaction mapping

Normalising a CSV bank export

A bank statement parser for CSV has to make decisions that XML makes for you. A sensible order:

1. Detect encoding and delimiter. Many European exports use semicolons because the comma is the decimal separator.
2. Fix the number format. Convert "1.250,00" to 1250.00 before any arithmetic, and store amounts as integer cents.
3. Fix the date locale. "03.11.2026" and "11/03/2026" can be the same day; a CSV date locale bank importer must be told the format rather than guess it.
4. Unify the sign. Some banks use a minus sign, others a separate debit/credit column.
5. Keep the raw row. Store the original line next to the normalised record so every match can be traced back.

You can check a CSV file's structure in the browser with our bank statement CSV validator.

Is there an invoice reconciliation API from DIGITAL EUR?

No. PLANNED: we have a draft design for a versioned REST API with idempotent allocation requests, but it is not built and there is no API to call, so we cannot offer a working reconciliation API example. DEMO, available now: the reconciliation lab runs in your browser on comma-separated CSV files with dot decimals, up to 2 MB and 20,000 rows. camt.053 import is also planned; our bank statement import page tracks it.

If you want to test an invoice matching algorithm of your own, the demo's rules make a useful reference case. Each candidate gets named reasons: invoice reference +65, exact amount +20, counterparty IBAN +10, counterparty name +5, possible partial payment −15 and amount exceeding the outstanding balance −25. No candidate is proposed without reference, IBAN or name evidence, equal top scores are marked ambiguous, and a person approves every match. A good test set includes at least one payment with no reference, one partial payment, one overpayment and two invoices with the same amount. The full logic is described on our reconciliation product page.

Common mistakes when reading the digital euro documentation

• Treating pilot specifications as production rules. The ECB marks the back-end specification as indicative and subject to change.
• Assuming any developer can connect. Access is for PSPs and those working on their behalf.
• Reading the SDK as an open developer kit. It is a component for PSP apps.
• Confusing conditional payments with programmable money. The ECB rules out programmable money; see our innovation page.
• Planning B2B flows on it. The current design targets retail payments.
• Trusting "digital euro API access" offers. No one can sell access to the DESP.

A practical checklist for technical teams

1. Download the rulebook v0.91 annexes D1 and D2 and the pilot back-end specification, and note their dates.
2. Load the pilot YAML file into your API tooling to explore the data model, not to build production code.
3. Map the ISO 20022 status and reason codes to the ones your systems already use.
4. Review your idempotency and retry logic against the Request-Id rule.
5. Check how CPACE, nexo and Berlin Group standards affect your terminals, checkout or app.
6. Decide whether you are a PSP, a technical service provider, a merchant or a tool vendor, because that decides your route.
7. Recheck the documents after each rulebook release and after the regulation is adopted; our news page records dated changes.

What is still unknown?

• When a final rulebook and final implementation specifications will be published.
• Whether a public simulator or test environment will be offered to non-PSPs.
• How certification of third-party software will work in practice, beyond the draft Annex A1.
• How the pilot specification will change after pilot feedback.
• Whether and when the digital euro will be issued, which the ECB will decide only after the legislation is adopted. Our timeline tracks the conditions.

Frequently asked questions

Is there an official digital euro API I can use?

No. The DESP APIs are documented for pilot PSPs, but there is no public or production API, no API keys and no public sandbox as of 5 November 2026.

Where can I find the digital euro developer documentation?

On the ECB's rulebook page and its "Technical documents and research" page. The most detailed items are the rulebook v0.91 annexes D1 and D2 and the pilot back-end specifications of 23 April 2026.

Is the digital euro API based on ISO 20022?

Partly. The pilot specification uses ISO 20022 data types and status codes where available, wrapped in REST and JSON interfaces, and reuses Berlin Group and CPACE work.

Can a fintech or start-up get access?

Not directly, unless it is a licensed PSP selected for the pilot. It can work as a technical service provider for a PSP or apply to ECB innovation activities if eligible.

Will merchants need to integrate a digital euro API?

Not with the ECB. Merchants would use the checkout or terminal solution of their acquiring PSP.

Does DIGITAL EUR offer a digital euro API?

No. We do not process digital euro payments and have no access to the DESP. Our reconciliation software works with today's euro bank data.

Sources

• ECB, Digital euro scheme rulebook (draft v0.91 and annexes, 2 July 2026) (accessed 5 November 2026)
• ECB, Digital euro pilot – Back-end implementation specifications, 23 April 2026 (PDF) (accessed 5 November 2026)
• ECB, Technical documents and research (accessed 5 November 2026)
• ECB, Digital euro pilot (accessed 5 November 2026)
• ECB, FAQs on the digital euro pilot (accessed 5 November 2026)
• ECB, Summary of workshops with technical service providers, 19 March 2026 (PDF) (accessed 5 November 2026)
• ECB, ECB signs agreements with European standard setters to facilitate digital euro payments, 24 April 2026 (accessed 5 November 2026)
• ECB, Piero Cipollone, introductory statement at the ECON committee, 3 June 2026 (accessed 5 November 2026)
• ECB, Digital euro service providers selected, 2 October 2025 (accessed 5 November 2026)
• ECB, Contract notice: Digital euro – App and SDK (PRO-009488) (accessed 5 November 2026)
• ECB, Network service providers selected for the digital euro, 30 October 2026 (accessed 5 November 2026)
• Mambu Payments, camt.053.001.08 XSD schema and business logic (secondary source for element names; accessed 5 November 2026)