Integrate with Dealer Engage

Integrate Your Solution with Dealer Engage!

Features of the Dealer Engage API include:
Supports transfer over HTTPS

Ability to have multiple keys and to revoke keys
Manage your contacts without logging in

API Overview
The Dealer Engage API is based on HTTP and implements many of the recommendations set out in the REST (Representational State Transfer) system architecture. The API follows the following REST constraints:

The API is a client-server API. You initiate a connection directly to Dealer Engage servers, which will respond with the result of your request.

Uniform Interface
The interface of the API is represented as resource URIs. Discovery of resources is provided by links returned in representations.

Each request is atomic. Authentication is provided on a per-call basis (there are no sessions).
The Dealer Engage API supports transfers over HTTPS to help ensure that your data is secure. Authentication is done using a combination of a public identifier key and a secret key. You may have multiple key pairs, which you can revoke at any time. These key pairs are available in the account management section of the Dealer Engage application when you’re logged in.

Directly Connecting via HTTP
Connecting to the API via direct HTTP requests is a much more involved process than using one of the wrappers. Constructing a request requires you to set up the appropriate headers and message body, and to place the request to a URL using a particular HTTP method. Details on these steps are provided below.

Request Method
The request method will be one of: GET, POST, or DELETE. These are operations that are performed on a resource. The documentation for each endpoint will specify the resource and the method to use.

Request URL
Requests are made to a particular URL. The URL represents either a resource which is either a collection or an single entity.

In general, you can retrieve multiple entities by calling GET on a collection, and can create a new entity by calling POST on a collection (since the new resource location is specified by us and not the caller in most cases, we use POST instead of PUT). An example of a collection of lists:

Entity resources, in general, can be retrieved by GET, modified with POST and permanently removed with DELETE. An entity on the previous collection would use an identifier (a list ID, in this case) following the collection, like so: