How unified APIs work with custom fields

Grace Woods
3 min readFeb 22, 2019


This article was originally published here

Kloudless provides a unified API that enables developers to integrate several software apps with a single implementation.

Unified APIs like Kloudless provide an abstraction layer to handle the different data models that each third-party service defines. The API layer provides a common set of functionality, and fills in gaps where needed. For this to be possible, there needs to be a large degree of overlap in data and functionality offered by all the vendors within each API category. For example, the Kloudless Storage API assumes each storage vendor’s API provides access to file and folder data, and offers functionality that lets Kloudless make complex features like cross-cloud search, links, and activity monitoring available on top of it

However, business apps increasingly allow users to customize the structure and type of data present within their accounts. Even with cloud storage, services like Dropbox, Box, SharePoint, and Google Drive now allow users to define custom properties and metadata on files, such as tags. Google and Outlook calendar also allow custom properties on calendar events.

This is especially prevalent in object-based systems of record such as CRM and Finance systems. Salesforce, Microsoft Dynamics, and other popular CRM systems not only allow users to define custom properties on objects, but also allow users to create entirely custom objects themselves. REST APIs don’t usually handle this level of variation in object formats, let alone REST APIs that also attempt to unify formats.

To address this concern, a unified API can provide meta APIs that describe object schema and also extend its own data models with custom attributes. The sections below describe how Kloudless implements both these options.

Object Schemas

The CRM services mentioned above provide API endpoints to describe object schema. For example, the Salesforce API possesses a describe endpoint for each object type. Here’san example that returns information on the fields in the object. The Kloudless API unifies these endpoints to provide a generic way to retrieve information on third-party object schema via the Kloudless API. Check out the List Schemas endpoint for more information.

Apps can use these schemas to display the object’s fields to a user and enable users to select the fields to map data to. This includes custom fields as well as custom object types.

Accessing custom attributes and objects

Continuing with our example with CRM providers, several core concepts exist among all CRM systems, including Accounts, Contacts, Leads, Opportunities, and Tasks. This lends itself to a unified API to allow apps to quickly integrate with several CRM services and access sales data across them. The ideal approach to access custom user-defined metadata is to extend this API.

All Kloudless APIs support accessing the raw metadata that Kloudless unifies via the X-Kloudless-Raw-Data: true header. This helps to read in any custom attributes on an object. For example, here are unified API fields alongside a raw attribute when retrieving a CRM Account:

Use the same object structure to create and modify custom attributes alongside unified ones. Here’s an example of an API request to create a CRM account in Salesforce, extended with Salesforce-specific data (BillingCity) and a custom tenant-specific field (kloudless__SLASerialNumber__c):

Kloudless also provides a generic objects endpoint to access, create, and modify entirely custom objects through the CRM API.

The approaches above provide a mechanism to access systems of record and customize a unified API’s implementation to individual end-users. Other alternatives include providing a unified query language instead to perform the operations above through a SQL-like interface. Check out Kloudless’ query language implementation for CRM here as well as the rest of our unified CRM API for more examples.

Authored by and with permission from Vinod Chandru