How Our CEQL Compares to SQL Queries

By David Honan in GET/technical Posted Feb 20, 2018

Our Elements are the root of what we do, but don’t call them Connectors, it doesn’t do them justice. Their job is to provide a standard way to connect to endpoints, regardless of the nuances of each given endpoint, and frankly, is not as easy as it sounds.


One of these subtleties is with the query language required to filter data when retrieving it from an endpoint using API resources - it ranges from slight variations of SQL queries to OData or XML RPC filter queries. Some endpoints have their own, modified version of SQL queries (e.g. Bullhorn) in order to meet their specific search use cases, others use specialized query languages like SPARQL (e.g. Docustore).

Why is this important in your integrations? Because querying for specific data is required to meet so many use cases, for example, search for:

  1. Contacts that have been modified since a specific date.
  2. Specific contact by email? Determines POST vs. PATCH
  3. Contacts added recently, ordered by lastName

As a developer that is in the throws of adding multiple integrations to a product, you are faced with discovering, researching/learning, developing, and testing each endpoints specific query language capabilities. You need to know how to apply them to your specific product use cases. Essentially, you have to become an expert in each and will likely have to build an entire framework just for this piece alone.

As a product manager, it is doubtful that you have the resources to support your developers in their quest to hook up the variety of endpoint query languages in your product. That $$ is better spent on adding capabilities and features to your product to keep you competitive in the marketplace.


So what does Cloud Elements do about this?

When we build an Element and add to our catalog, we normalize the query language to our standard called Cloud Elements Query Language, or CEQL. This is very similar to SQL queries and thus very little learning curve - just a simple where clause and you are good to go.

CEQL Examples:

  1. where=Name LIKE ‘%Foo%’
  2. where=Name=’Foo Account’ AND Industry=’Biotechnology’
  3. Name=’GenePoint’ OR (Industry=’Biotechnology’ AND LastModifiedDate>’2015-01-01T00:00:00.000Z’)

What about when the endpoint’s native query capabilities are not variations of SQL? How does Cloud Elements translate CEQL to the native query language?

Here are some examples:

SOAP, e.g. Netsuite, Salesforce Marketing Cloud (ExactTarget), and Autotask:

OData, e.g. Dynamics, SAP C4C, GoodData, Microsoft Graph, etc.



XML RPC, e.g. Intacct:



As you can see, the Element is more than a connector - it can speak query across many different languages so you don’t have to.

And, just when you thought CEQL was exciting enough as is, guess what else an Element uses CEQL for? You got it, for our Eventing Framework to poll the endpoint for changes and also for Bulk APIs to query for and retrieve data in quantity. Elements rock.

Additional information about CEQL, specific to a given Element, check out our API Documentation on the endpoint you care about, e.g. for Salesforce. 

View our API Documentation