At billwerk, we consistently follow the API-First approach, because APIs are of central importance for service-to-service communication. The billwerk API is based on the REST paradigm and thus enables a smooth connection of your own systems to billwerk. The data transfer is carried out in the JSON format, which can be easily converted into other programming languages.
Integration directly and via third-party systems into almost any application and system landscape. The integration possibilities are completed by webhooks, which take over a complementary task by notifying the customer system.
An interactive solution that interacts with existing and future technologies.
Easy implementation and integration with existing solutions and tools. Extension of automation possibilities.
billwerk uses the most widely used specification format for HTTP-based APIs. Using Swagger, the documentation of the billwerk REST interface is stored directly on the code. The extensive automation ensures that the documentation grows evenly with the system and is adapted when changes are made. As a user, you can try out the REST API directly with your sandbox account.
For a fast and efficient start with billwerk, we have already developed and provided a large number of ready-to-use integrations to the most important payment providers (e.g. PayPal, Adyen, PAYONE, GoCardless, Stripe, SlimPay) and relevant SaaS applications for you.
Learn more about Rest API
Communication between different servers requires an interface that enables data exchange. One of the most used interfaces is REST API (Representational State Transfer – Application Programming Interface). The programming interface was developed in 2000 by Roy Fielding.
Today, most applications are connected to the Internet in one way or another. Different mobile devices like smartphones or tablets and very different systems require the use of interfaces like REST API. It enables communication from machine to machine, as the different devices and systems have to be connected to each other.
The REST API interface enables the systems to distribute data and tasks to different servers or to retrieve them with an HTTP request. Nowadays a large part of the Web services is REST-compatible.
The functionality of the REST API is based on HTTP requests that access information using PUT, GET, POST and DELETE. REST is frequently used because it allows connection to cloud services and enables interaction. More specifically, transactions are broken down and divided into a number of smaller modules.
There are six different constraints that a service should have:
Client server model
With REST, there is a clear separation between data storage and user interface, so clients are easier to adapt to different environments and platforms, and servers are easier to scale.
A client and server must be able to exchange stateless data. Each request from the client must contain all the necessary information, since the server itself does not have a stored context. This increases reliability, visibility and scalability. On the other hand, there may be disadvantages in network speed and client control.
To increase network efficiency, clients store certain server responses and retrieve them later for similar requests. However, the responses must be marked as “cacheable” or “non-cacheable”. This promotes a responsive application with greater scalability and efficiency, but also carries the risk that clients may revert to outdated data from the cache.
A simplified architecture and increased visibility are to be guaranteed by the use of a uniform interface decoupled from the service. Therefore one also takes a reduced speed into account, since through the standardized interfaces data must always be converted to a certain format.
Clearly separated, multi-layered systems with hierarchical structure as with the REST API lead to the fact that e.g. legacy applications can be encapsulated. The resulting increased security, however, also results in higher latencies and greater auxiliary information.
Code on demand
The extension of loadable and executable program parts (e.g. as scripts or applets) is optional and can be deactivated.