We started Aurinko with the Unified API similar to that of Nylas but as we worked more and more on various CRM and ERP integrations we understood that a unified API for a whole vertical of providers (like CRM or ERP) is often an overkill. Integrations are often very app specific (one or two objects) and a more custom unification approach may be better.

For example, we’ve been helping a customer of ours to build a CRM sync (kind of bidirectional deal registration) between their CRM platform and another mainstream CRM (like Salesforce, Sugar, Netsuite) that could migrate mainly the Opportunity related data (Line items, products) but in very intricate ways, supporting a ton of customizations that existed in Salesforce or Sugar. So the focus here is depth rather than breadth of those APIs. And so an app specific virtualization / unification was needed here, more like the one CloudElements invented.

Aurinko Virtual API

Ever since I learned about CloudElements’ virtual data resources I thought it was a great idea. Although we decided to take a slightly different approach, unify and virtualize the data model (crm objects) rather than the API endpoints. We define just those virtual objects that our integration needs (100s of CRM objects are not required for our specific sync).

Here is how one of the mappings looks like (using a Salesforce account), our virtual objects:

Inside the Opportunity object, field mappings (now using a Sugar CRM account):

Child relationships - this is a concept from Salesforce metadata which seems quite relevant for business systems.

The API endpoints are defined implicitly:


What you get is a unified API, but it’s virtualized by you to your specific integration needs. And isn’t that what you really need in most cases?

As I wrote in Unified Metadata API the “lowest common denominator effect” and API intricacies are quite a challenge for unified APIs so Aurinko also allows you to capture some useful metadata in the mappings. Like the SYNC_USER_LOOKUP tag that communicates some custom behavior to the API consumer code. Our sync code implements the contact lookup in a custom way.

Many more mapping features are supported already. I’ll cover them in another blog post.