Unify Logo Footer.svg
Platform Tools
Logo
Connector SDK Overview

Connector SDK Overview

Logo

4 mins READ

On this page

Building your own connector to integrate an app that isn't already built in.

Overview

A custom connector is an integration you build yourself, in the Custom Connectors area, for an app or API that UnifyApps doesn't already provide. Once built and deployed, it behaves like any built-in connector: people create connections to it and use its actions and triggers inside automations. You define four things — how to authenticate, the actions it can perform, the triggers it can listen for, and connector-wide settings. You describe each as configuration (the auth flow, the HTTP request an action makes, the response shape), and the platform runs it for you. This is the Connector SDK: a builder for turning an HTTP API into a first-class UnifyApps connector.

Screenshot_2026-09-02_at_12.24.35_PM_1.png
Screenshot_2026-09-02_at_12.24.35_PM_1.png

Parts of a custom connector

A connector bundles:

  • Authentication — how a user connects: the auth type (OAuth 2.0, Access Token, Basic, JWT, custom, …), the credentials they supply, and how those are applied to every request.

  • Actions — operations the connector can perform (create a record, send a message). Each defines its input, the HTTP request it makes, and its output.

  • Triggers — events the connector can react to (a new record, an incoming webhook). Each also has an input, a request, and an output.

  • Settings — connector-wide configuration: the objects it exposes and which modules (Automations, Data Pipelines, Data Catalog) can use it.

Actions and triggers are the two resource types a connector exposes; everything else supports them. Each action and trigger is individually deployed (or paused) to control its availability.

Building a connector end to end

The typical path:

  1. Create the connector — name it and set its base URL.

  2. Add authentication — choose an auth type and define the inputs a connecting user provides.

  3. Add actions — from scratch or by importing an OpenAPI spec; for each, define its input, the request it makes, and how its response maps to outputs.

  4. Add triggers — polling or webhook triggers for the events you want to react to.

  5. Configure settings — the objects it exposes, which modules can use it.

  6. Deploy each action and trigger, then create a connection and use them in an automation — they run through the same pipeline as production.

FAQs

How does the platform run a custom connector?

You define a connector as configuration; the platform's connector runtime executes it. When an action or trigger runs, the runtime: loads your connector's definition, retrieves the user's connection and decrypts its credentials — refreshing them first if they've expired — builds the request by filling your templates with the inputs and credentials, applies the authentication, sends the call (with automatic retries for transient failures), and maps the response back into the resource's outputs. You never run a server — you describe the calls, and the platform handles connection management, credential refresh, sending, retries, polling pagination, and response parsing.

What can a custom connector talk to?

Custom connectors call HTTP APIs — REST-style JSON APIs primarily, and the runtime also handles XML/SOAP-style responses and file downloads. The request builder is HTTP through and through: method, URL, headers, query parameters, body. (The platform's built-in connectors internally cover other protocols — databases, message queues, file transfer, email — but the custom connector builder itself defines HTTP requests; if the app you're integrating speaks HTTP, you can build a connector for it.)

Last updated : 03 September 2026, 01:20 PM

On this page