Connectivity FAQ
What is a connector?
Connectivity on the App Xchange platform includes both connectors and connections between the platform and external products or applications. The ability to interact directly with external applications is a key part of the integrations built on the platform, in which data is pulled from and delivered to those applications.
The connector is effectively an intermediary between the App Xchange platform and an external product, database, or application. The connector provides integration capabilities in the form of pre-built data objects with actions that can be used to build data transformations and flows.
In effect, a connector may be thought of as the interface between a product and the App Xchange platform, enabling integrations to be built with that product. A connector is needed for any product to be made available on the platform.
Why build a connector?
The key benefits of deploying a connector on the App Xchange platform include:
Availability to the existing App Xchange user base already developing integrations with other connected products and applications.
Connecting a product to the App Xchange platform can ease the path to adoption for users of other connected products. Build one connector for an application, and get access to integrate with many other applications that already have connectors on the platform.
Pre-built integrations: building a connector enables developing pre-built integrations on top of it that may cover a variety of common use cases.
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.
Authentication
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:
OAuth 2.0
Authorization Code - not yet supported
Documentation
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.
Endpoints
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.
Development
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:
Initial onboarding: We'll engage directly with new teams to prepare any needed components and provide initial direction.
Build as needed for integration use cases: This will depend on the integrations to be enabled and may involve continued engagement with the App Xchange team on platform capabilities and documentation.
Deploying to production: The connector build approval and deployment pipeline is evolving. This page will be updated as further documentation becomes available on the connector lifecycle.
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:
Interview current users with custom-built direct integrations (e.g., leveraging an API directly) to weigh their interest in using the connector (for example, if they'd prefer not to continue investing in the current development effort).
Evaluate the cost, if any, of building integrations on behalf of existing users who cannot develop their own.
Analyze user behavior to determine if churn or attrition is due in any part to the cost (or lack of) integration paths available.
Perform an analysis of products with complementary features or data to evaluate if a connector may provide an adoption path of benefit to them or their users.
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.
What data isolation options are available on the platform?
Currently, data brought into the platform is located in North America (US).
The App Xchange team is currently evaluating user needs to prioritize expanding data isolation capabilities in alignment with Trimble policies on data privacy and protection. If there is a need for any particular data isolation options to build a new App Xchange connector or integration, please let us know.
Trimble's data protection and security programs are comprehensive and based on globally accepted standards, including the GDPR.