Why API?

{api:dab}: Bringing the power of APIs to micro, small and medium-sized enterprises

System Integration


Supply Chain

Data Publication

The Non-Developers Guide to APIs

In recent years RESTful APIs have become the standard way of creating a secure means of exchanging data between different computers. They are routinely the building blocks of modern web and mobile apps, particularly where developers are avoiding the building of cumbersome 'monolithic' systems. Additionally, APIs can also be used to exchange data between computers and electronic devices or AI systems. These APIs can be provided for both your internal departmental consumption, as well as for the benefit of external parties where required. Traditional API development methods can be extremely expensive, with high cost of ownership, and is simply beyond the reach of small business.   {api:dab} redresses that commercial inbalance.

An API can publish or collect data and can even be programmatically commissioned to allow API consumers to update or even delete data records, subject to data security and the application of the data. In development terms, this is known as CRUD functionality (Create, Read, Update, Delete). The {api:dab} platform allows your administrative users to elect which API methods are available to general users, or to disable some methods altogether. Our CRUD functionality supports the following methods:

  • GET:   Retrieve all records, a selection of records or a specific record
  • POST:   Create a brand new record
  • PUT:   Completely replace an existing record
  • PATCH:   Replace certain fields (only) of an existing record
  • DELETE:   Delete an existing record entirely

To see all available methods in action, please go to the API Demo page

APIs are known as RESTful - here is a quick definition:

In common with standard web pages, systems that follow the REST paradigm are stateless, meaning that the server does not need to know anything about what state the client is in and vice versa. In this way, both the server and the client can understand any message received, even without seeing previous messages. But this is not important to understand in technical terms for users of {api:dab}, as we take care of these technical details for you.

APIs are beautifully simple and consequently, blisteringly fast when serving or writing data...

Simple Interdepartmental Use Case (Read-only)

So how about a simple example of an API in action:

Imagine we needed to develop an application that relied upon looking up Full Name, Department, Role and Telephone Extension data for an organisation. The Human Resources department appears to be a good candidate for accurate and timely versions of this data, as it is responsible for maintaining company records of all employees, so presumably has the very latest version within its computer systems. HR systems are tightly controlled, as they additionally hold confidential information about members of staff, including salary and performance reviews. Therefore, it would not be appropriate to open up every field of data to our new application.

Prior to the availability of API technology, our options would be to either input to our own version of the Full Name, Department, Role and Telephone Extension data, which has high potential for inaccuracies over time or we could periodically export the required data from the HR system and import into the new application database. We can see that both non-API methods require ongoing maintenance in order for the data to match that of the HR system, being the primary source of information of this type. Worse than that, if our application were to be out of date, there could be embarrassing situations that arise where we have users of the application calling members of staff that have moved extension, department or even left the organisation altogether.

In modern APIs, the form of the data sent from or received by the API is in a structure known as JSON (JavaScript Object Notation).

Called from our API, the top two records would look like this:

{"FullName": "David Copper",
"Role": "Director",
"Department": "Research & Development",
"Extension": 5107,
"email": "david.copper@deterix.com"},
{"FullName": "Jeremy Kwee",
"Role": "Supervisor",
"Department": "Administration",
"Extension": 5208,
"email": "jeremy.kwee@deterix.com"}

Our client application would know exactly what to do to process that format and the developer could choose to display any or all of the fields, in any order that they choose. And, they do not need to have the entire record set every time they call the API - they can just call the record where the FullName is 'David Copper', or even where the Role matches 'Director'. The users of the remote system can be sure that they are receiving the very latest version of the data (often in real-time) and leverage the one-truth data principle, dispensing with multiple copies of the same data, internal or external to the organisation.

Simple External Supply Chain Use Case (Read & Update)

Here we have another real-world example - this time for the use by an external party:

If we were a supplier of goods to a client, we can easily see how useful it would be for the client to use an API to lookup the real-time stock levels we are holding for one of our products (READ) and then go on to use the very same API to adjust our stock balance as a result of an order (UPDATE). A common and effective use case for an external API deployment, that saves time, makes it easy for the client to order our product and, via convenience, in many ways provides a compelling reason for the client to conduct business with our organisation. This appears to be particularly useful in the context of a just-in-time (JIT) inventory model.

But as we will see, this type of external API doesn't need to be limited to physical products, as we explore a services based scenario below.

Imagine that our client is an insurance company and we are a third party administrator (TPA) handling specialist claim notifications (we will use professional indemnity claims as our example) on behalf of that underwriter. In this scenario, you could also be an insurance litigation law firm handling more complex claim issues and suggesting reserves to the insurer.

In many cases a TPA will be using their own claims portal and produce a monthly bordereau, or in a more sophisticated environment, give the insurer direct access to a claims and MI portal. Law firms may be leveraging their internal case management system in a similar way. It is also common that a central notification mailbox is operated by the insurer, to which the claims handling unit or lawyer will forward claims and circumstances received, with suggested reserves and maximum possible loss figures. This has traditionally worked well, but does rely on import of the bordereau to the insurer's own reserving system, or even manual input to the insurers own systems.

Now let us add seamless and timely integration between the two disparate systems:

Taking the TPA example as our potential API integration, we can see how the insurer system can augment or even replace the bordereau and portal solution, adding some powerful reporting, auditing and accounting functionality that can be incorporated into a workflow context.

Our TPA is the first point of notification for professional indemnity claims on behalf of the insurer. Notifications will be claims or circumstances, with the TPA having a delegated authority to settle the claims. The TPA may be operating an Escrow Account that the insurer adds funds to, allowing swift settlement of the claims that fall within the delegated authority, which in this case is GBP10,000 per claim.

So with a handful of simple APIs consumed by the Insurer, we could potentially extend the functionality to transform our workflow:

  • Notify new claims and circumstances immediately, with the insurer passing their claim reference allocated back to the TPA
  • The insurer system can call the latest reserving and payment position on a claim, or group of claims, in real-time
  • Suggested reserves can be agreed or even amended by the insurer based upon their reserving philosophy
  • Reserves and payments falling outside of the delegated authority can be agreed or rejected by the insurer
  • File closing or re-opening can be communicated to the insurer in a timely fashion

The above are just a selection of possible features - there are many more possible with this type of API integration.

Below is a sample of the types of data that could be communicated:

{"InsuredName": "Lois & Partners LLP",
"TPAClaimRef": "PI2099348823",
"InsurerClaimRef": "LP1988327723",
"WorkType": "Commercial Conveyancing",
"CauseCode": "Failure to know the law",
"ClaimDate": "2020-01-02",
"CCY": "GBP",
"MPL": 122990,
"ClaimReserve": 55000,
"DefenceCostReserve": 16000,
"ClaimantCostReserve": 18500,
"ClaimPaid": 0,
"DefenceCostPaid": 5000,
"ClaimantCostPaid": 0,
"TotalIncurred": 94500,
"TPAFee": 450,
"RiskNumber": "77349923"}

This simple illustration only covers a small part of the overall integration that could be achieved - there are myriad applications of the technology. But it is clear to see that with no development work, a super-user at our TPA can add meaningful value to the commercial relationship using {api:dab}.

{api:dab} : Publish data via API in minutes!

So Easy!

Extend your IT System Client Reach...

{api:dab}: Bringing the power of APIs to micro, small and medium-sized enterprises


Copy data into a CSV or DB FIle


Upload data to your {api:dab} server


Create secure API via {api:dab} Wizard


Supply the API Key to your Client

Why our service should be at the center of your Use Cases...

API Design & Build is a comprehensive SaaS platform that enables non-Development staff to design and publish secure RESTful APIs in minutes, via a highly intuitive non-programming interface. Literally anyone can do it right out of the box. But it's not just about convenience - even a very simple API can cost thousands to have developed via traditional routes and usually takes weeks or even months to deploy. Add to that the secure server hosting and maintenance required and we can see that the power and convenience of the {api:dab} service can give your business an incredible competitive advantage and help bring your API initiatives to fruition well ahead of the rest of the market.


If you’re using software as a service (SaaS), you can use the internet to access that system whenever and wherever you are. You just need an internet connection and the ability to log into the system via a web browser. You can be on a desktop computer, phone, or PC. You can be at the office, home, or at the airport. It doesn’t matter, as long as have access to WiFi.

The application runs on our powerful servers, with {api:dab} responsible for the security, performance, and maintenance of the platform. We have the economy of scale and you have the peace of mind that the service will always be available to your own clients. As new features are added to our system, your business is the direct beneficiary of our commitment to API excellence - as well as providing a beautifully simple development environment, we are effectively managing your whole Use Cases too.

Once you have deployed your APIs, you can monitor their usage with real precision using our sophisticated management information (MI) console. This really is a complete 360 degree API solution.

Creating & Managing APIs via our Intuitive Interface

The Security of Two-Factor Authentication (2FA)

Our history is one of controlled and steady growth, our approach is based on professional, technical, human and environmental standards which have evolved over time on a foundation of strong and clear business principles. All this is combined in an unswerving commitment to our clients, our people and our shared objectives.

Create and Host a totally free API Here!

super easy . super secure . super value