We're glad that you're trying out Cloud Elements 2.0 and hope you use this section to learn where to find more information and get familiar with our terminology.
For this page, I would either get a lot more detailed, or a lot less detailed. Less detailed: i would provide only the basics: Elements, Element instances, Formulas, Formula instances, formula executions, VDRs, object definition, transformation.
OR, a lot more detailed and cover everything.
Documentation and Resources
If you have found your way to this page, you're at least familiar with our documentation. We have many resources available to help you create integrations. Here in the Help Center, you can find API reference documentation, knowledgebase articles, guides that provide detailed instructions, and documentation about each of our elements.
Use the search at the top of the page to find information anywhere in the Help Center.
As you use the Help Center, and especially as you work through the Getting Started guide, we encourage you to provide feedback so we can give you the best docs experience possible.
API Hub <--- is this still used / needed?
An API Hub (Hub) provides uniform APIs to access a collection of resources enabling one-to-many API access to multiple API providers. For example, the CRM hub provides normalized access to multiple CRM application services including Salesforce, Microsoft Dynamics, Netsuite CRM, Sugar CRM, Zoho CRM, and Autotask (we call a connection to each service an element). Your application can write to the “One” uniform API and get access to “Many” application services in that category. Within the CRM Hub, Cloud Elements has normalized the API calls to multiple resources such as Accounts, Contacts, Leads, Opportunities and more. Hubs represent the intersection of resources across the elements within that category of application services.
We normalize our API calls for all endpoints, to enable calls between services e.g., Salesforce to HubSpot. However, with this feature, certain endpoint resources cannot be mapped for each hub.
- Hubs provide uniform APIs to access any collection of elements or a set of resources.
- Hubs enable “One-to-Many” access to an entire category of services.
- Hubs are accessed using a consistent RESTful API with a JSON payload regardless of the technology used at the endpoint.
- Hubs rapidly translate calls into the semantic and data structure required by each endpoint.
- Hubs provide a uniform set of interactive API documentation that developers use to access the resources in the Hub.
- Hubs combine resources from multiple categories providing a consistent set of APIs and documentation to access any collection of resources (e.g., combine Salesforce, Box, and QuickBooks API resources into a Hub).
An authenticated element instance is a single authenticated connection between Cloud Elements and an account at an API provider such as a Salesforce, Marketo, or Netsuite. An authenticated element instance can access all the objects, fields, and data for that account — including custom data. An authenticated element instance is created when a user successfully connects to the endpoint by providing an instance name, the required authentication credentials for that element, and optional event configuration.
Bulk APIs enable you to move large amounts of data. Cloud Elements provides the ability to upload and download data in bulk from an endpoint in a normalized way. We leverage the provider bulk endpoints whenever available. But, when the API provider has no bulk endpoints, we provide a pseudo bulk service for uploading and downloading data from the endpoint. For uploads, we accept a file, and then create objects at the endpoint on a record-by-record basis. For downloads, we execute a search API against the endpoint, and loop through all results until we have retrieved all the data. Cloud Elements stores the files (encrypted) on Cloud Elements servers for a maximum of seven days.
CEQL stands for Cloud Elements Query Language, the search and filter language used by Cloud Elements to standardize searching across all our different elements. Many APIs support some form of searching in their APIs but they’re almost all different, so we have standardized a common way to search across all our elements. Cloud Elements translates the CEQL to the endpoint’s searching syntax, however at times, CEQL supports more than the endpoint.
Virtual Data Resource
A virtual data resource is a stand-alone resource, created and defined by a user with the intention of creating a one-to-many transformation. Virtual data resources define normalized fields that you can use in place of specific elements to facilitate one-to-many integrations. You map fields from element resources to the virtual data resource fields to create transformations.
Cloud Elements includes a comprehensive data discovery service that provides normalized metadata, such as the list of field names and types. Additional information, if available from an endpoint, may also be obtained such as: display name, read-only, etc. If an endpoint doesn’t provide discovery service APIs, Cloud Elements will still provide a minimum set of metadata about the given resource (e.g., name and type). Cloud Elements also allows you to discover custom fields (as long as the values are not empty), by supplying an object Id when a native discovery service is not available. The Discovery Service is used along with the Transformation Service to normalize the responses across endpoints.
Elements are pre-built API integration that enables a connection into a specific API Provider endpoint (e.g., Salesforce, Quickbooks, or Marketo). All elements start with a normalized set of features, including authentication, resources, paging, errors, events and search. At the hub level, we also seek to support the richer set of APIs that an application provides, even when not all the elements in that category share that resource. For example, Salesforce Sales Cloud has APIs that many other CRM services do not support. You can find these APIs that are specific to just Salesforce in the documentation for that element
- Elements share common services including discovery, search query, pagination, bulk uploading and downloading, logging, and interactive documentation.
- Methods are normalized and accessible through RESTful APIs.
- Complete data payloads are returned in JSON and available to transform and normalize to a virtual data resource.
- Cloud Elements keeps each element up-to-date with changes at the endpoint.
- Each element is a multi-tenant connector supporting an unlimited number of authenticated accounts with no additional code required.
A unique URI that represents a resource and includes the HTTP method and resource. it includes the method (GET, PUT, PATCH), the base URL, and the resource.
An action that occurs at an API provider associated with an authenticated element instance and is monitored either through Polling or Webhooks.
A specific instance of a formula template configured with explicit variables and associated with specific element instances.
A formula template is a reusable workflow that is independent of the element and includes the triggers, steps, and variables for a formula instance to execute the workflow. The steps in a formula template accomplish a wide variety of use cases across different services, such as keeping systems in sync, migrating data between systems, and automating business workflows.
The OAuth Proxy feature gives you the capability to have multiple environments, such as development, QA, etc, with one endpoint application. For example some vendors only allow one callback URL per application. The proxy will allow for the same callback URL to be used with multiple application endpoints. You would then use the proxy address as the Callback URL instead of your own Callback URL. This permits multiple endpoint applications to one callback URL.
The data returned from an API response. Or, the body of an API request.
An object or entity that can be accessed via a URI request.
A Transformation is the result of mapping an API provider resource to a virtual data resource. This allows you to define the fields to include in a specific resource, map those fields to the fields containing the same data in the provider resource, and then transform the data to match the virtual data resource.