How to Configure a Connector
  • 08 Jul 2024
  • 3 Minutes to read
  • Contributors

How to Configure a Connector

Article summary


Connectors enable integrations between external systems and databases. For more information, see “What Are Connectors?.”

How to Create a New Connector

Setting up a new connector doesn’t require extensive knowledge of APIs or databases, but familiarity with connection types is helpful.

To create a connector, navigate to the Connectors page under Apps. Click + Create Connector in the top right corner. You can either select an existing Library connector or click Create Custom Connector.

Setting Up a New Connector


Basic Information

  1. Add a name and description for your connector. These can be edited at any time.
  2. Select a connector type. This cannot be changed after the connector has been created.
  3. [optionally] Enable custom subdomains allows you to configure unique subdomains for each function, facilitating integration with more complex service architectures.

For example, if the server address is, function one might use and function two might use

When custom subdomains are enabled, a default subdomain must be provided to check the connector status.

Running on: Connector Host

Select the Connector Host that will execute your requests. The Cloud Connector host, provided by Tulip, makes requests via the Tulip Cloud. Any on-premise connector host registered to your account will also appear. More information on Connector Hosts is available here.

Connector Host Capabilities

Some connector hosts do not support certain features. These hosts will be disabled or hidden in the connector host dropdown.

HTTP Setup

Server Address

Specify the network address, i.e., a hostname or IP address, that Tulip connects to.


Transport Layer Security (TLS) is a cryptographic protocol designed to provide secure communication over a computer network. It ensures data privacy and integrity by encrypting the data transmitted between parties. TLS is the successor to Secure Sockets Layer (SSL) and is widely used to secure internet connections.


Your server listens to requests on a specific networking port provided by your server provider. Port 443 is the most common for HTTPS services, and port 80 is the most common for HTTP services.



  • No Auth - No authentication needed, or the authentication is within other request headers like x-auth-token.
  • Basic Auth - Basic authentication, which implements username and password.
  • OAuth 2.0 (Bearer token) - Bearer tokens are the predominant type of access token used. They consist of an opaque string, not meant to have meaning to clients using it.
  • OAuth 2.0 (User Credentials) - Typically used for clients that require access to a limited set of resources on behalf of a user, such as a mobile app needing access to a user's contacts or calendar events. The user must explicitly grant permission.
  • OAuth 2.0 (Service Account) - Used for clients that require access to a wider range of resources or administrative functions. This role grants extensive access to the user's account and resources, such as managing account settings, creating or deleting resources, or performing administrative tasks.
  • OAuth 1.0 - An earlier version of OAuth that mainly handles web workflows.

More information on OAuth is available here.

Headers (Optional)

Headers provide data origin authentication, data integrity, and replay protection. These headers will be added to every connector function on the connector.

Extending Certificate Authorities


.pem formatted files can be uploaded to extend the default Node.js TLS Certificate authorities. This field updates the ca field in the Node.js TLS library.

"Optionally override the trusted CA certificates. Default is to trust the well-known CAs curated by Mozilla. Mozilla's CAs are completely replaced when CAs are explicitly specified using this option. The value can be a string or Buffer, or an array of strings and/or Buffers. Any string or Buffer can contain multiple PEM CAs concatenated together. The peer's certificate must be chainable to a CA trusted by the server for the connection to be authenticated. When using certificates that are not chainable to a well-known CA, the certificate's CA must be explicitly specified as a trusted or the connection will fail to authenticate. If the peer uses a certificate that doesn't match or chain to one of the default CAs, use the ca option to provide a CA certificate that the peer's certificate can match or chain to. For self-signed certificates, the certificate is its own CA and must be provided. For PEM encoded certificates, supported types are "TRUSTED CERTIFICATE", "X509 CERTIFICATE", and "CERTIFICATE". See also tls.rootCertificates."

An example valid CA should look something like this:


Was this article helpful?