Tendrl

Docs / Strand / nodes/connectors

Connector Nodes

Connector nodes use saved connectors to interact with external services, providing reusable authentication and centralized configuration.

Overview

Connector nodes allow you to:

Benefits
- Store credentials securely (encrypted)
- Update credentials without changing workflows
- Share connectors across multiple workflows
- Test connectors independently

Connector Capabilities

Each connector has a direction that describes what it can do, and one or more operations you can select when configuring a node.

Direction Meaning
Read / Write Can both send data to and retrieve data from the service
Write Only Can only forward/send data to the service (fire-and-forget)
Read operations load data into the workflow
Read operations (e.g., S3 get_object, SQS receive_message) read data into the node's output payload as JSON. They do not download or save files to disk.

Quick Reference

Connector Direction Operations
HTTP REST API Read / Write GET, POST, PUT, PATCH, DELETE, HEAD
MQTT Write Only Publish
AWS S3 Read / Write Upload Object, Download Object, List Objects
AWS SQS Read / Write Send Message, Receive Message
AWS SNS Write Only Publish
AWS EventBridge Write Only Put Events
AWS Lambda Read / Write Invoke Function
Azure Blob Storage Read / Write Upload Blob, Download Blob
Azure Service Bus Write Only Send Message
Azure Event Grid Write Only Publish Event
Azure Queue Storage Read / Write Send Message, Receive Message
Google Cloud Storage Read / Write Upload Object, Download Object
Google Pub/Sub Read / Write Publish, Subscribe
Google Firebase FCM Write Only Send Notification
Google Firestore Read / Write Set Document, Get Document, Query Collection
AI Connectors (OpenAI, Anthropic, Gemini) Read / Write Chat Completion
MCP Server Read / Write Tool Call (auto-discovered)
Contact Entity Message Write Only Send Message, Send File
Tendrl Email Write Only Send Email
SMTP Email Write Only Send Email
Slack Write Only Send Message, Update Message, Add Reaction
Discord Write Only Send Message, Send Webhook, Add Reaction
Telegram Write Only Send Message, Send Photo, Send Document
Twilio Write Only Send SMS
Google Sheets Read / Write Read Range, Write Range, Append Rows
Redis Read / Write Get, Set, Delete, Publish
Apache Kafka Read / Write Produce, Consume
Home Assistant Read / Write Call Service, Get State, Fire Event, Render Template
AWS DynamoDB Read / Write Put Item, Get Item, Query
AWS Kinesis Read / Write Put Record, Get Records
AWS CloudWatch Read / Write Put Metric Data, Get Metric Data, Put Log Events

Connector Health Monitoring

Strand tracks connector health with a circuit breaker pattern:

Security and credentials

These guarantees apply to every connector; individual pages don't repeat them:

---

Platform Nodes

These nodes are always available in the node selector and do not require a saved connector instance; they integrate with built-in Tendrl platform services. They appear alongside the connector nodes when you add a node.

Surface: Scan Payload (platform.surface.scan)

Scans payload content for threats using Surface and returns a threat level, score, and indicators of compromise.

Configuration:

Field Required Description
content Yes Payload content to scan. Supports Jinja templates.
reject_on No Comma-separated threat levels that set safe=false. Default: malicious.
profile_id No Scan profile to use. Leave empty for the account default.
label No Optional label for the scan (supports Jinja).
timeout No Request timeout in seconds, 5–120 (default: 30).

Output: scan results are written flat onto the payload (not wrapped in a data envelope):

Field Description
threat_level Clean, Informational, Suspicious, or Malicious (title-case; reject_on matching is case-insensitive)
score 0-100 safety score (higher is safer)
iocs List of indicators of compromise
primary_threat Name of the primary detected threat
recommended_action Recommended handling action
safe true unless threat_level is in reject_on
service surface

Branch on the result with an If/Else Logic node, e.g. {{ payload.safe }} or {{ payload.threat_level == 'malicious' }}.

Contact: Send Message (platform.contact.send)

Sends a message via Contact using an entity API key.

Configuration:

Field Required Description
api_key Yes Contact entity API key. Supports Jinja (e.g. {{ vault.contact_key }}).
dest No Destination entity name.
tags No Comma-separated routing tags.
data No Message data payload.
timeout No Request timeout in seconds, 5–120 (default: 30).

Output: the standard request envelope (data, status) with service: contact and operation: send added; an error field is set on a failed status.

Contact: Send File (platform.contact.send_file)

Sends a file into Contact using an entity API key (Contact file transfer). The sending entity needs the entity:SendFiles permission and pays storage until the file is consumed.

Configuration:

Field Required Description
api_key Yes Contact entity API key. Supports Jinja (e.g. {{ vault.contact_key }}).
content_base64 Yes File bytes, base64-encoded. Defaults to {{ payload.content_base64 }} so it chains straight from a Contact: Fetch File or HTTP node.
file_name No File name including extension (drives Contact's file-type allowlist).
content_type No MIME type; inferred from the extension if omitted.
dest No Recipient entity name or resource path, for direct / group / cross-account delivery.
tags No Comma-separated routing tags that route the file to subscribing Strand workflows/connectors.
kind No Set to clip for the motion gallery (no recipient).
meta No Optional sender metadata, ≤8 KB (supports Jinja).
timeout No Request timeout in seconds, 5–120 (default: 30).

Set exactly one delivery target: dest, tags, or kind: clip. See Delivery modes for how each routes.

Output: on success, transfer_id, sha256, size, and mode are added to the payload alongside service: contact and operation: send_file. A Contact rejection (missing entity:SendFiles permission, over the monthly-data or size limit, an unsupported file type, or a file flagged by Surface) fails the node.

Contact: Update State (platform.contact.update_state)

Updates an entity's state table in Contact.

Configuration:

Field Required Description
api_key Yes Contact entity API key (supports Jinja).
entity Yes Entity name to update (supports Jinja).
state Yes State data to write (supports Jinja).
replace No true replaces the entire state table; default merges.
timeout No Request timeout in seconds, 5–120 (default: 30).

Output: the standard request envelope with service: contact and operation: update_state added; an error field is set on a failed status.

---

HTTP Connectors

Direction: Read / Write

Comprehensive HTTP connector for REST APIs, webhooks, and HTTP-based services.

HTTP Connector Configuration

Required:

Optional:

Authentication Options

None

No authentication (default).

Basic Authentication

json

{
  "type": "basic",
  "username": "myuser",
  "password": "mypassword"
}

Bearer Token

json

{
  "type": "bearer",
  "token": "your-token-here"
}

API Key

json

{
  "type": "api_key",
  "api_key_header": "Authorization",
  "api_key_value": "your-api-key",
  "api_key_location": "header"
}

Location options:

OAuth2

json

{
  "type": "oauth2",
  "oauth2": {
    "token_url": "https://oauth.example.com/token",
    "client_id": "your-client-id",
    "client_secret": "your-client-secret",
    "scope": "read write",
    "grant_type": "client_credentials"
  }
}

Grant types:

AWS Signature V4

json

{
  "type": "aws_sigv4",
  "aws_sigv4": {
    "region": "us-east-1",
    "service": "execute-api",
    "access_key_id": "AKIAIOSFODNN7EXAMPLE",
    "secret_access_key": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
    "session_token": "optional-session-token"
  }
}

Service identifiers:

Custom Headers

json

{
  "type": "custom",
  "custom_headers": {
    "X-Custom-Auth": "{{ payload.token }}",
    "X-API-Version": "v2"
  }
}

HTTP Node Configuration

Override at node level:

HTTP Example

Connector Setup:

json

{
  "url": "https://api.example.com",
  "default_method": "POST",
  "auth": {
    "type": "bearer",
    "token": "secret-token"
  },
  "default_headers": {
    "Content-Type": "application/json",
    "X-Client-Version": "1.0"
  }
}

Node Usage:

Result: GET https://api.example.com/users/123 with Bearer token and custom headers.

---

MQTT Publish Connectors

Direction: Write Only

Publish messages to MQTT message brokers with support for TLS/SSL and authentication.

MQTT Connector Configuration

Required:

Optional:

TLS/SSL Configuration

json

{
  "tls": {
    "enabled": true,
    "ca_certs": "/path/to/ca-cert.pem",
    "certfile": "/path/to/client-cert.pem",
    "keyfile": "/path/to/client-key.pem",
    "cert_reqs": "required",
    "tls_version": "tlsv1.2"
  }
}

Options:

Quality of Service (QoS) Levels

MQTT Node Configuration

Required:

Optional:

MQTT Example

Connector Setup:

json

{
  "broker_url": "mqtts://broker.example.com:8883",
  "username": "mqtt_user",
  "password": "mqtt_password",
  "tls": {
    "enabled": true,
    "cert_reqs": "required"
  },
  "qos": 1
}

Node Configuration:

---

AWS Connectors

Amazon Web Services connectors for S3, SQS, SNS, EventBridge, and Lambda.

S3, SQS, and Lambda are Read / Write. SNS and EventBridge are Write Only (forward data).

Common AWS Configuration

All AWS connectors require:

AWS S3

Amazon Simple Storage Service for object storage.

Direction: Read / Write

Operations: put_object (write), get_object (read), list_objects (read)

S3 Node Configuration:

S3 Example:

AWS SQS

Amazon Simple Queue Service for message queuing.

Direction: Read / Write

Operations: send_message (write), receive_message (read)

SQS Node Configuration:

AWS SNS

Amazon Simple Notification Service for pub/sub messaging.

Direction: Write Only

Operations: publish

SNS Node Configuration:

AWS EventBridge

Amazon EventBridge for event-driven architecture.

Direction: Write Only

Operations: put_events

EventBridge Node Configuration:

AWS Lambda

Amazon Lambda for serverless function invocation.

Direction: Read / Write

Operations: invoke

Lambda Node Configuration:

---

Azure Connectors

Microsoft Azure connectors for Storage, Service Bus, Event Grid, and Queue Storage.

Blob Storage and Queue Storage are Read / Write. Service Bus and Event Grid are Write Only (forward data).

Azure Blob Storage

Direction: Read / Write

Configuration: Account Name, Account Key (encrypted), Container Name (optional)

Operations: upload (write), download (read)

Blob Storage Node Configuration:

Azure Service Bus

Direction: Write Only

Configuration: Connection String (encrypted), Queue Name or Topic Name (optional)

Operations: send

Service Bus Node Configuration:

Azure Event Grid

Direction: Write Only

Configuration: Endpoint URL, Access Key (encrypted)

Event Grid Node Configuration:

Azure Queue Storage

Direction: Read / Write

Configuration: Account Name, Account Key (encrypted), Queue Name (optional)

Operations: send_message (write), receive_message (read)

---

Google Cloud Connectors

Google Cloud and Firebase connectors for Storage, Pub/Sub, Firebase, and Firestore.

Cloud Storage, Pub/Sub, and Firestore are Read / Write. Firebase FCM is Write Only (push notifications).

Common Google Configuration

All Google connectors require:

Google Cloud Storage

Direction: Read / Write

Operations: upload (write), download (read)

Cloud Storage Node Configuration:

Google Pub/Sub

Direction: Read / Write

Operations: publish (write), subscribe (read)

Pub/Sub Node Configuration:

Google Firebase Cloud Messaging

Direction: Write Only

Push notifications via FCM.

FCM Node Configuration:

Google Firestore

Direction: Read / Write

NoSQL document database operations.

Operations: set (write), get (read), query (read)

Firestore Node Configuration:

---

AI/LLM Connectors

Direction: Read / Write

AI connectors provide LLM integration with prompting, system instructions, MCP tool access, automatic retries, and conversation memory across workflow runs. Supports OpenAI, Anthropic Claude, and Google Gemini.

See AI Connectors for full node configuration, output format, memory, and examples.

---

MCP Server Connectors

Direction: Read / Write

Model Context Protocol (MCP) server connectors provide external tool access for AI nodes. MCP connectors are selected at the AI node level, not used as standalone nodes.

Connector Configuration:

Using MCP with AI Nodes

  1. Create an MCP server connector with the server URL and authentication
  2. Add an AI connector node to your workflow
  3. In the AI node configuration, select the MCP server connector(s)
  4. The AI model can then invoke tools provided by the MCP server
Tip: You can attach multiple MCP server connectors to a single AI node, giving the model access to tools from multiple servers.

---

Contact Entity Message Connectors

Direction: Write Only

Send messages to contact entities in the Tendrl platform.

See Contact Message Connector for detailed documentation.

---

Email Connectors

Tendrl Email

Direction: Write Only

Send emails using Tendrl's managed email service. No server setup needed: just configure recipients, subject, and body.

See Tendrl Email Connector for detailed documentation.

SMTP Email

Direction: Write Only

Send emails using your own SMTP server. Full control over your email infrastructure.

See SMTP Email Connector for detailed documentation.

---

Slack Connectors

Direction: Write Only

Send messages and interact with Slack workspaces using a Bot Token. Post to channels, update messages, and add reactions.

Operations: send_message (write), update_message (write), add_reaction (write)

See Slack Connector for detailed documentation.

---

Using Connectors in Workflows

Selecting a Connector

  1. Add a Connector node to your workflow
  2. The connector selector appears
  3. Choose from your saved connectors
  4. Configure node-specific settings

Templating in Connector Configs

Many connector fields support Jinja2 templating:

---

Managing Connectors

Connectors are managed through the Connectors page:

  1. Navigate to Connectors from the sidebar
  2. Click "Add Connector" to create a new connector
  3. Select connector type and configure
  4. Edit or delete connectors from the list
  5. Filter by All, Configured, or Unconfigured types
Connector Management
- Group connectors by environment (Production, Staging, Development)
- Use naming conventions (e.g., AWS-Prod-S3, Azure-Dev-Storage)
- Regularly rotate credentials and update connectors
- Test connectors after credential updates

Best Practices

Tips
1. Create connectors for frequently used services - Reuse authentication and configuration
2. Use descriptive connector names - AWS-Production-S3, Azure-Staging-Storage
3. Store sensitive data in connectors - Never hardcode credentials in workflows
4. Update connectors when credentials change - All workflows using the connector automatically use new credentials
5. Test connectors before using - Verify configuration in connector manager
6. Use node-level overrides sparingly - Prefer connector defaults when possible
7. Document connector purposes - Add descriptions when creating connectors

Individual Connector Docs

← Back to Strand docs