This overview covers the resources that make up the official wunderbon API

The wunderbon API is the public frontend of wunderbon's multi identifier capable network. The network delivers smart receipts to Consumers smartphones and brings blockchain based security to issued receipts as well.

For developers (Merchants, POS Providers, Suppliers and us) it is important to know how to interact with the wunderbon API. This document provides a 360° design overview of the provided endpoints and on how to interact with them programmatically. wunderbon provides detailed information and insights on every single part of the wunderbon API.


Info & Status

wunderbon Projects wunderbon Projects Security Headers

The API status, as well as the status of all other self and third-party operated services can be checked here.


Transparency affects all areas of wunderbon like security do. wunderbon takes care of providing all relevant information for a deeper understanding of our business behind the transactions on our platform. In result transparency covers almost any of our business areas.

For more information about Transparency, see this section.


If we look at the issue of security, we will quickly see that it affects many areas. Security for us certainly primarily involves the handling of any data, regardless of whether a user is a Consumer, Merchant or Supplier.

For more information about Security, see this section.


wunderbon will always protect and respect every users privacy. wunderbon do its best to provide highest privacy standards enabling Consumers worldwide to adjust the level of privacy individually on a per Merchant or Supplier basis. Users will always be informed about how wunderbon handles data, what "your data" in this context is and how wunderbon use data to enable their business.

For more information about Privacy, see this section.


wunderbon does not try to reinvent the wheel. We do rely safely on an existing, modern blockchain providing support for smart contracts.

For more information about Blockchain, see this section.


We at wunderbon want to build a different type of company. A company that is focused on the happiness of our customers and team, and our personal growth along this journey. Our DNA leads us in our decisions and actions. Our DNA is made of good values and based on a new digital ethic.

For more information About Us, see this section.

Become a Partner

wunderbon is expanding its partnerships and network continuously and would like to invite you to join. No matter if you are a Merchant and want to issue digital receipts, if you are a POS-Provider ready for bringing an open smart receipt solution to your customers or if you are a Supplier (FMCG) who wants a stronger brand building channel - give us a call or write us an email - we would love to guide you through our product.

For more information about partnerships, see this section.


By default, all requests to https://api.wunderbon.io receive the latest version of the wunderbon API. wunderbon encourages you to explicitly request this Version via the Accept header.

For more information about requesting a specific Version, see this section.


When requesting data from an endpoint of the wunderbon API it may respond with a Resultset when successful or an Error in case something went wrong. Let us have a look at the first case: The Resultset is the data the wunderbon API returns on your request.

For more information about Resultsets, see this section.


Beside the parameterization like number of results per page or the attribute the results are ordered by or the offset to start described here, the wunderbon API supports more complex filtering. Only Resultsets returned by a collection can be filtered. The Filters are applied on the whole collection before it is returned from the server. Only the filtered Resultsets are returned.

For more information about filters, see this section.


There are two ways to authenticate through wunderbon REST API. Requests that require authentication will return 404 Not Found, instead of 403 Forbidden, in some places. This is to prevent the accidental leakage of private data to unauthorized users.

For more information about Authentication, see this section.


wunderbon uses a simple Role and Scope based access control system (RBAC/ABAC). A Role is a composition of Scope based access rights. A Scope is the representation of an entity (e.g. user). Access rights are subdivided into Create, Read, Update and Delete.

For more information about Authentication, see this section.

HTTP Verbs

The wunderbon API enables you to develop having all possible CRUD (create, retrieve, update, delete) operations. General API guidelines suggest using a specific HTTP Verb on a specific type of call made to the server. wunderbon follows the common standards.

For more information about HTTP Verbs, see this section.

HTTP Status Codes

The following lists all HTTP Status Codes returned by the wunderbon API. See section Endpoints to get an detailed insight into the HTTP Status Codes that are returned by a specific endpoint like [/users](/docs/endpoints-users).

For more information about HTTP Status Codes, see this section.

Rate Limiting

To ensure availability, stability and fair use wunderbon controls the frequency with which the wunderbon API can be accessed. However, the procedure known as Rate Limiting is designed so generously that all concerns are taken into account.

For more information about Rate Limiting, see this section.


wunderbon is basically able to run several parallel instances of the network with different addresses (so called Environments). In our case these are currently the Mainnet with address 0x01 and the Testnet with address 0xFF.

For more information about Environments, see this section.


The wunderbon network supports external networks in addition to the native wunderbon network with its wunderbon account number (WAN). The list of supported providers is curated, and only certified partners are connected.

For more information about Networks, see this section.


The wunderbon network does not only support different Providers but also Identifiers with different "Versions". Sometimes Identifiers are evolving like our network does. So wunderbon supports versioning of Identifiers. Versioning e.g. ensures that different patterns can be validated correctly and realtime checked as well.

For more information about Identifiers, see this section.


Some requests that create new data, such as creating a new receipt, allow you to provide timezone information when specifying or generating timestamps.

For more information about Timezones, see this section.


There is always at least one stable version of the wunderbon API. You will find detailed information on the current and/or latest version here.

When using the API v1, wunderbon encourages you to request v1 either via the Accept header or via .

What’s Next

Continue with our guided tour. Now we would like to tell some more about how we handle Transparency at wunderbon ...