An API is a set of definitions and protocols that facilitate the creation and integration of application software. It is sometimes seen as a contract between an information provider and an information user, which defines the content requested from the consumer (the call) and the content requested from the producer (the response).
We accept REST APIs only. REST is a set of architectural constraints. It is neither a protocol nor a standard. API developers can implement REST in a number of ways.
Blobr is the no-code SaaS to help you share your APIs with the world in the best possible way. Blobr is a SaaS for business users to productize and control how they share their APIs while providing the best possible experience to the final users of the API products. Therefore our SaaS is split between the Workspace product for business users and the Developer Portal generated for developers.
Blobr's vision is to foster the use and share of data between B2B companies. Our vision is to productize data assets so it becomes easy for business users to share and monetize data.
We have a tier pricing business model based on the features included and the number of calls going through Blobr. There is a plan with different thresholds fitting different needs. If the monetization option is used within Blobr, we get a 5% commission of the revenue generated thanks to Blobr. You can see more details on the pricing page.
To start using Blobr, you need to grant Blobr access to your REST API by uploading the definition file in our app. Then, from our Blobr interface, you have three different options. You can either:
-> Semi-automatically document the API you want to share and manage through our autoload feature per endpoint you want to document.
-> Manually detail all endpoints and related datapoints.
-> Upload the open API specs you might have created (Swagger 2.0 or OpenAPI 3.0. references).
At Blobr, we have created a build factory with automated daily tests. We push our developments to production only when we have 100% success on the tests. The production workflow is even further tested as it is redirected to pre-production to perform additional testing on new features we release before it gets to production environment.
In addition, Blobr is based on pure serverless relying on AWS gateway with geo-redundancy, idempotency. With such an infrastructure in place, we can ensure there will never be downtime higher than 10sec "by design".
At Blobr, we provide a direct integration with Stripe. To start using this integration, all you need to do is create an account in parallel on Stripe and register your API keys in the Blobr app. To monetize your API products, you have several options: from subscription models with or without quotas to metering and tiered pricing.
Those different options are either tied up to API calls or to other metrics (e.g. number of end-users). From the checkout and payment to generation of invoices, everything is properly managed through Blobr.
Blobr can be divided into 2 parts sitting on different types of infrastructure:
-> Blobr Workspace for the API Provider
This one is used to create API products, monetization, define limits, etc... This one is deployed in one region but is actually available everywhere in the world. It is working like a mobile app. However, it is completely unrelated to the API proxy.
-> Blobr API Proxy
This one manages API accesses. This is the part enabling access to API clients. There is geo-redundancy of the API proxy with idempotency. It means that the proxy behaves in the exact same way, whatever the region. AWS is checking every 10 seconds among deployed regions the one answering the fastest.
As a consequence, by design, the maximum consequence of an SLA problem would be 10 seconds consecutively as there is a fallback mechanism moving from one API proxy to another in case of a longer response time. The proxy is only based on one function and updates are extensively tested beforehand. In the worst-case scenario, if there are bugs in the Blobr API provider interface, the API proxy is still able to manage as per the rules.
Yes, you can use your own authentication solution and still manage accesses by clients the way you do it. You just need to require from your clients to add in the header the x - blobr API - key generated for them when calling the API.
Yes, with Blobr you can customize the DNS so that the base URL for calling your APIs is based on your DNS you choose. You have this option in Blobr back-end interface to customize the DNS easily. Once selected in Blobr interface you need to update your name server type records to put in your DNS manager (e.g. Godaddy or other) to validate the delegation.
The versioning part can be managed at the level of the products created in Blobr. Some products for the same API may be backed by a new version of API while others cannot. The upload of a new API in Blobr considered as a new version of a previous API will identify what the breaking changes are to prevent from versioning risk for the users/customers of the original API.
The versioning part is therefore enabled by allowing API URLs to be linked from one to another by chaining calls from one version to another. For example, if the version 1 API is applied to a client with an object containing 4 datapoints in response, the version 2 which contains 5 datapoints (one additional datapoint) can be transmitted to the client without him changing the key. When a client calls the version 1 API, the call can automatically be remapped by Blobr to the version 2 API.
Some information and actions performed within Blobr can be accessed through a REST API. More specifically, all info that is available in the Blobr analytics part can also be accessed through an API.
API management solutions have been built by developers for developers. You need to be a developer to use them. They were originally built to manage internal APIs and have used the same principles to try to adapt to external APIs. At Blobr, we believe External APIs should not be treated as Internal APIs.
It requires a specific solution that can be used by business users to productise their APIs and provide the best possible experience.
We create a latency of about 40 milliseconds per API call. For most use cases not tied up to trading data, it has no impact on the final user experience.