Connectivity FAQ

Why build a connector?

The key benefits of deploying a connector on the App Xchange platform include:

What do I need to build a connector?

It can be helpful to begin with an initial use case, or an example of the type of integration that would be developed using the connector. The connector may provide for initial use cases to begin with and can be extended upon later as needed.

To connect to a product or backend application, an API will be needed. The connector can be thought of in part as an API client, in which the API endpoints correlate to the data objects and actions that will be defined in the connector and thereby made available to integrations and flows on the platform.

The checklist below can be useful in evaluating the fitness of an API to be leveraged as a connector interface:

API Type

In general, an HTTP or REST API will be used for building a connector. If needed or preferred, other types of API may be employed, for example GraphQL, RPC, or SOAP. In this event, please let us know.

The App Xchange team is currently working to enable using asynchronous events (e.g., Kafka streams) or webhooks for SDK-built connectors. This page will be updated to include further details when available.

The topics below focus primarily on an HTTP/REST API. Equivalent functionality would be needed for any other type of API used.


Integrations on the platform depend on executing flows on behalf of users without their direct intervention, and therefore non-interactive API authentication is preferred with the following authentication types being supported:


OpenAPI ≥ 3.0 is generally preferred for HTTP/REST API documentation. If well prepared, it can facilitate an informed evaluation of the API a connector will leverage; but it is not a requirement for building a connector on the platform.

The connector SDK will automatically prepare OpenAPI documentation for the connector API (not to be confused with the API of the connected product or application) that will be available to users building integrations with the connector.

There is not (yet) an automation for deriving a connector from an OpenAPI specification, but we do plan to introduce that capability.


The API ought to include endpoints and HTTP verbs (or methods) correlating to the resources (data objects) and operations (actions) needed to build integrations with the connected product or application.

For example, if an integration would depend on the ability to get a list of projects from a backend database, a GET /projects endpoint would likely be needed. To get data on an individual project, an endpoint like GET /projects/{id} could be used. POST, PATCH, PUT, and DELETE operations will typically be needed for creating, updating, and deleting entries.

In practice, this will largely be a question of evaluating the integrations for which a connector will be used and confirming if the API facilitates them. The connector may provide for initial use cases to begin with and can be extended upon later as needed.

Filtering and Pagination

The API endpoints ought to include any parameters needed to filter and/or edit the data being queried or created, too.

In particular, filtering typically ought to include the ability to query for changed data based on a date or time frame and pagination to limit the amount of data transferred per call.


The SDK documentation provides further details on how to begin. This content is linked for Trimble developers and will become publicly available in the near future.

The App Xchange team is currently working to enable on-prem and private cloud abilities for SDK-built connectors. This page will be updated to include further details when available.

What is the estimated level of effort to build a connector?

The level of effort involved in building a connector will depend in large part on the complexity of the application or product and of the integrations the connector will enable. That can be evaluated in a number of ways, and can be mitigated by prioritizing the most in-demand features needed.

Building a connector may be thought of as including three phases of work:

What is the pricing model of connectors on the platform?

There is no extra direct cost to an end user to leverage a standard connector on the platform.

In App Xchange for Products, typically used by technology company developers building integration products for their users, there is a limit to the number of connectors non-enterprise users can leverage per integration. This is a pricing tier for the platform not directly tied to any individual connector. That limit does not apply to App Xchange for Contractors, typically purchased by end users building their own custom integrations.

If there is a cost to use the connected product or API, the user can pay that directly (not in App Xchange). The user will be able to enter any credentials provided if needed for the connector on App Xchange. 

The benefits of providing a connector include access to integration with a variety of other applications on the platform, encouraging adoption of the connected product.

How can I evaluate the revenue potential of building a connector?

Even if a product or application enables direct integration capabilities, for example by providing an API, typically only developers will be able to leverage it, and they will need to invest in building custom logic to achieve the integrations needed. This may be a barrier to adoption for potential users, which can be difficult to quantify accurately.

It may be useful to evaluate the demand for a connector by performing any of the following exercises:

In general, the most-used features of a product can be identified based on current usage patterns, log data, and user engagement or feedback. This data can be leveraged to better understand what kinds of integration are in demand. By focusing on these when building a connector, broader adoption can be enabled with lower initial development effort, thereby maximizing earning potential.

It can be difficult to quantify this in general terms, in that the data will vary widely between products or applications. 

By focusing early development on targeted integrations and prioritizing the most in-demand features, the investment to build a connector can be effectively managed while beginning to collect initial data on its usage by early adopters on which to base enhancements later if needed.

In addition, by enabling new custom or pre-built integrations on the platform, long-term adoption of the connected product or application will be encouraged.