Lindy CI Integration

Overview

Lindy agents run on Lindy's managed platform — CI/CD tests your integration code: webhook receivers, callback handlers, and application logic that interacts with Lindy agents. Test webhook signature verification, payload processing, and error handling without hitting live Lindy endpoints.

Prerequisites

• GitHub repository with Actions enabled
• Lindy API key and webhook secret stored as GitHub secrets
• Node.js project with webhook receiver code
• Completed lindy-install-auth setup

Instructions

Step 1: Store Secrets in GitHub

gh secret set LINDY_API_KEY --body "lnd_live_xxxxxxxxxxxx"
gh secret set LINDY_WEBHOOK_SECRET --body "whsec_xxxxxxxxxxxx"

Step 2: Create GitHub Actions Workflow

# .github/workflows/lindy-integration.yml
name: Lindy Integration Tests

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: '20'
          cache: 'npm'

      - run: npm ci

      - name: Run unit tests
        run: npm test
        env:
          LINDY_WEBHOOK_SECRET: ${{ secrets.LINDY_WEBHOOK_SECRET }}

      - name: Validate webhook handler
        run: npm run test:webhook

      - name: Connectivity check (non-blocking)
        continue-on-error: true
        run: |
          curl -s -o /dev/null -w "%{http_code}" \
            -X POST "https://public.lindy.ai/api/v1/webhooks/health" \
            -H "Authorization: Bearer ${{ secrets.LINDY_API_KEY }}"

Step 3: Write Webhook Handler Tests

// __tests__/webhook-handler.test.ts
import { describe, it, expect, vi } from 'vitest';
import request from 'supertest';
import { app } from '../src/server';

describe('Lindy Webhook Handler', () => {
  const VALID_SECRET = process.env.LINDY_WEBHOOK_SECRET || 'test-secret';

  it('rejects requests without auth header', async () => {
    const res = await request(app)
      .post('/lindy/callback')
      .send({ event: 'test' });
    expect(res.status).toBe(401);
  });

  it('rejects requests with wrong auth token', async () => {
    const res = await request(app)
      .post('/lindy/callback')
      .set('Authorization', 'Bearer wrong-token')
      .send({ event: 'test' });
    expect(res.status).toBe(401);
  });

  it('accepts requests with valid auth token', async () => {
    const res = await request(app)
      .post('/lindy/callback')
      .set('Authorization', `Bearer ${VALID_SECRET}`)
      …

Lindy Common Errors

Overview

Troubleshooting guide for Lindy AI agent errors. Lindy agents fail at specific points in the workflow: trigger reception, action execution, condition evaluation, or exit condition evaluation. This guide covers each failure class.

Prerequisites

• Access to Lindy dashboard (https://app.lindy.ai)
• Ability to view agent Tasks tab for error details
• For webhook debugging: curl installed

Instructions

1. Capture the failing run identifier, trigger payload shape, and first failing step without copying sensitive fields into the incident record.
2. Reproduce the behavior in a test agent or disabled workflow using a bounded input.
3. Apply the smallest trace-supported remediation, then rerun both the failure fixture and a normal-success fixture before restoring schedules.

Trigger Errors

Webhook Not Firing

Symptoms: No task created when webhook is sent Causes & Solutions:

# Diagnostic: Test webhook connectivity
curl -v -X POST "https://public.lindy.ai/api/v1/webhooks/YOUR_ID" \
  -H "Authorization: Bearer YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"test": true}'
# Expect: 200 OK

Email Trigger Not Activating

Symptoms: Emails arrive but agent does not wake up Solutions:

1. Verify Gmail/Outlook authorization is current (re-authorize if expired)
2. Check label filter — Lindy Email Received trigger can filter by label
3. Confirm email matches trigger filter conditions (sender, subject, etc.)
4. Check that agent is active, not paused

Schedule Trigger Missed

Symptoms: Agent did not run at scheduled time Solutions:

1. Verify timezone settings match your expectation
2. Check credit balance — agents stop if credits exhausted
3. Review schedule configuration (daily vs weekday vs custom)

Action Errors

Slack Send Failed

Lindy Core Workflow A: Agent Creation

Overview

Complete workflow for creating, configuring, and testing Lindy AI agents. Agents consist of four components: Prompt (behavioral instructions), Model (AI engine), Skills (available actions), and Exit Conditions (completion criteria).

Prerequisites

• Lindy account at
• Use case defined (support bot, email triage, data processor, etc.)
• Required integrations identified (Slack, Gmail, Sheets, etc.)

Instructions

Step 1: Define Agent Specification

Before building, document:

• Purpose: What the agent does (one sentence)
• Trigger: What wakes it up (webhook, email, schedule, chat, etc.)
• Actions: What it does (send email, update sheet, post to Slack, etc.)
• Model: GPT-4 (smart, expensive), Claude Sonnet (balanced), Gemini Flash (fast, cheap)

Step 2: Create the Agent

Option A — Natural Language (recommended):

1. Click New Agent at
2. Describe your agent in plain English:

   When a customer emails support@company.com, classify the email as
   billing/technical/general, draft a response using our knowledge base,
   and post the classification to #support-triage in Slack

1. Agent Builder auto-generates trigger + action nodes

Option B — Manual Build:

1. Click New Agent > Start from scratch
2. Add trigger: Click "+" > Select trigger type
3. Add actions: Click "+" > Search for action
4. Connect nodes by dragging arrows between steps

Step 3: Configure the Prompt

Open Settings > Prompt. Structure it with clear sections:

## Identity
You are a customer support classifier and responder for [Company].

## Instructions
1. Read the incoming email carefully
2. Classify into: billing, technical, or general
3. Search the knowledge base for relevant answers
4. Draft a professional response using the KB results
5. If no KB match found, escalate to human

## Constraints
- Never promise refunds or credits without human approval
- Keep responses under 200 words
- Always include ticket reference number

Prompt best practices (from Lindy docs):

• Use action-oriented language (imperatives)
• Break complex logic into numbered steps
• Include few-shot examples for consistent formatting
• Add constraints to prevent unwanted behavior

Step 4: Add Conditions (Branching Logic)

1. Click "+" > Condition
2. Write …

Lindy Core Workflow B: Triggers & Multi-Agent Automation

Overview

Configure trigger-based automation, scheduled agents, and multi-agent delegation ("Societies of Lindies"). Covers all trigger types, trigger filters, multiple triggers per agent, and the Agent Send Message delegation pattern.

Prerequisites

• Completed lindy-core-workflow-a (agent creation)
• Integrations authorized (Gmail, Slack, etc.)
• For delegation: multiple agents created

Instructions

Step 1: Configure Trigger Filters

Trigger filters add conditional logic that determines WHICH events wake the agent. Filters are not case-sensitive and support AND/OR operators with condition groups.

Email trigger filter example:

Filter: sender contains "support" AND subject does not contain "auto-reply"

Slack trigger filter example:

Filter: channel equals "#help-desk" AND message contains "urgent"

Step 2: Multiple Triggers (Same Workflow)

One agent can respond to multiple trigger types feeding into the same workflow:

1. Create first trigger (e.g., Webhook Received)
2. Click "New Trigger" to add a second (e.g., Email Received)
3. Connect grey arrows from both triggers to the first action step
4. The agent processes both identically

Step 3: Multiple Workflows (Different Triggers)

A single agent can run entirely different workflows based on trigger type:

• Trigger A (Email Received) -> Classify + Draft Reply
• Trigger B (Chat Message) -> Search KB + Respond in chat Each trigger connects to its own action chain.

Step 4: Schedule-Based Triggers

For recurring automation (daily reports, weekly digests):

1. Add trigger > Schedule
2. Configure timing: Every weekday at 9:00 AM
3. Options: daily, weekly, monthly, or custom cron
4. The agent runs automatically at the scheduled time

Step 5: Calendar Event Trigger

For meeting-related automation:

1. Add trigger > Calendar Event Start
2. Set Minutes Offset:

• -30 = trigger 30 minutes BEFORE event
• +5 = trigger 5 minutes AFTER event starts

1. Use case: Pre-meeting briefing agent pulls attendee data and sends summary

Step 6: Multi-Agent Delegation (Societies of Lindies)

Build modular agent systems where specialized agents collaborate:

Architecture:

[Lead Generator Lindy]
    ↓ Agent Send Message
[Outreach Lindy]
    ↓ Agent Send Me…

Lindy Cost Tuning

Overview

Lindy uses a credit-based pricing model. Every task costs credits based on model size, step count, premium actions, and duration. Cost tuning targets: model right-sizing, agent consolidation, trigger optimization, and credit monitoring.

Prerequisites

• Lindy workspace with billing access
• Multiple active agents to evaluate
• Dashboard access to review per-agent task history

Credit Cost Reference

Plan Costs

Instructions

Step 1: Audit Agent Credit Consumption

For each active agent, collect:

1. Task count (last 30 days) — from Tasks tab
2. Average credits per task — total credits / task count
3. Model used — from agent settings
4. Trigger frequency — how often the agent fires

Create a cost audit table:

Step 2: Right-Size Models

The highest-impact optimization. For each agent, ask: > "Does this task actually need GPT-4/Claude, or would Gemini Flash work?"

Lindy Data Handling

Overview

Lindy agents process data through triggers, LLM calls, actions, knowledge bases, and memory. Data flows through Lindy's managed infrastructure with AES-256 encryption at rest and in transit. This skill covers data classification, PII handling, prompt-level data controls, and regulatory compliance.

Prerequisites

• Understanding of data types processed by your agents
• Knowledge of applicable regulations (GDPR, CCPA, HIPAA)
• For HIPAA: Business Associate Agreement (BAA) with Lindy (Enterprise plan)

Lindy Data Architecture

Instructions

Step 1: Classify Data in Agent Workflows

Map what data each agent processes:

Step 2: PII Controls in Agent Prompts

Add data handling instructions directly to agent prompts:

## Data Handling Rules
- Never include full email addresses in summaries — use "[name]@[domain]"
- Redact phone numbers in logs — show only last 4 digits
- Do not forward customer personal information to Slack channels
- When storing to spreadsheet, omit columns: email, phone, address
- If asked to share customer data externally, decline and escalate

Step 3: Knowledge Base Data Safety

Knowledge base files are searchable by the agent. Control what goes in:

DO upload:

• Product documentation
• FAQ articles
• Policy documents
• Public knowledge articles

DO NOT upload:

• Custome…

Lindy Debug Bundle

Current State

!node --version 2>/dev/null || echo 'Node.js not installed' !python3 --version 2>/dev/null || echo 'Python not installed' !curl --version 2>/dev/null | head -1 || echo 'curl not installed'

Overview

Systematic diagnostics for Lindy AI agent issues. Collects environment info, tests API connectivity, reviews agent task history, and generates a support bundle for Lindy's support team.

Prerequisites

• Access to Lindy dashboard (https://app.lindy.ai)
• curl installed for API testing
• Agent ID and webhook URLs available

Instructions

Step 1: Collect Environment Info

# Local environment diagnostics
echo "=== Local Environment ==="
echo "Node: $(node --version 2>/dev/null || echo 'N/A')"
echo "Python: $(python3 --version 2>/dev/null || echo 'N/A')"
echo "OS: $(uname -srm)"
echo "Date: $(date -u '+%Y-%m-%d %H:%M:%S UTC')"
echo "LINDY_API_KEY set: $([ -n "$LINDY_API_KEY" ] && echo 'yes' || echo 'NO')"
echo "LINDY_WEBHOOK_SECRET set: $([ -n "$LINDY_WEBHOOK_SECRET" ] && echo 'yes' || echo 'NO')"

Step 2: Test Webhook Connectivity

# Test webhook trigger endpoint
echo "=== Webhook Connectivity ==="
WEBHOOK_URL="${LINDY_WEBHOOK_URL:-https://public.lindy.ai/api/v1/webhooks/YOUR_ID}"

# Test without auth (expect 401)
echo "Without auth (expect 401):"
curl -s -o /dev/null -w "HTTP %{http_code} in %{time_total}s\n" \
  -X POST "$WEBHOOK_URL" \
  -H "Content-Type: application/json" \
  -d '{"test": true}'

# Test with auth (expect 200)
echo "With auth (expect 200):"
curl -s -o /dev/null -w "HTTP %{http_code} in %{time_total}s\n" \
  -X POST "$WEBHOOK_URL" \
  -H "Authorization: Bearer $LINDY_WEBHOOK_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"test": true, "debug": "bundle-test"}'

Step 3: Review Agent Task History

In the Lindy dashboard:

1. Navigate to the failing agent
2. Open the Tasks tab
3. Filter by Failed status
4. For each failed task:

• Note the timestamp
• Click to expand step-by-step execution
• Identify the failing step (marked red)
• Copy the error message and input/output data

1. Look for patterns: same step failing? same time of day? same input type?

Step 4: Check Integration Health

# Test outbound connectivity to common Lindy…

Lindy Deploy Integration

Overview

Lindy agents run on Lindy's managed infrastructure. Deployment focuses on your integration layer: webhook receivers, callback handlers, and application code that Lindy agents interact with via HTTP Request actions and webhook triggers.

Prerequisites

• Lindy agents configured and tested
• Application with webhook receiver endpoints
• Deployment platform (Vercel, Railway, Docker, AWS, GCP)
• Lindy API key and webhook secrets

Instructions

Step 1: Prepare Application for Deployment

// src/server.ts — Production-ready Lindy webhook receiver
import express from 'express';
import helmet from 'helmet';

const app = express();
app.use(helmet());
app.use(express.json({ limit: '1mb' }));

// Health check for load balancer
app.get('/health', (req, res) => {
  res.json({
    status: 'ok',
    timestamp: new Date().toISOString(),
    version: process.env.APP_VERSION || 'unknown',
  });
});

// Lindy webhook receiver with auth verification
app.post('/lindy/callback', (req, res) => {
  const auth = req.headers.authorization;
  if (auth !== `Bearer ${process.env.LINDY_CALLBACK_SECRET}`) {
    return res.status(401).json({ error: 'Unauthorized' });
  }

  // Respond immediately, process async
  res.json({ received: true });

  // Async processing
  processWebhook(req.body).catch(err => {
    console.error('Webhook processing error:', err);
  });
});

async function processWebhook(payload: any) {
  const { taskId, status, result } = payload;
  // Your business logic here
  console.log(`Task ${taskId}: ${status}`, result);
}

const PORT = process.env.PORT || 3000;
app.listen(PORT, () => console.log(`Listening on :${PORT}`));

Step 2: Docker Deployment

# Dockerfile
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --production
COPY dist/ ./dist/
EXPOSE 3000
ENV NODE_ENV=production
HEALTHCHECK --interval=30s --timeout=3s \
  CMD wget -qO- http://localhost:3000/health || exit 1
CMD ["node", "dist/server.js"]

# Build and run
docker build -t lindy-integration .
docker run -d \
  -p 3000:3000 \
  -e LINDY_CALLBACK_SECRET="$LINDY_CALLBACK_SECRET" \
  --name lindy-app \
  lindy-integration

Step 3: Vercel Deployment

# Install Vercel CLI
npm i -g vercel

# Set secrets
vercel secrets add lindy-callback-secret "$LINDY_CALLBACK_SECRET"

# Deploy
vercel --prod

// vercel.json
{
  "env": {
    "LINDY_CALLBACK_SECRET": "@lindy-callback-secret"
  }
}

Step 4: Update Lindy Agent Webhook URLs

After deployment, update all…

Lindy Enterprise RBAC

Overview

Lindy organizes access around workspaces where agents live. Team members are assigned roles that control who can create, modify, run, or observe agents and their execution history. Enterprise features add SSO, SCIM, audit logs, and granular permission controls.

Prerequisites

• Lindy Team ($49.99/mo + $19.99/seat) or Enterprise plan
• Workspace owner privileges
• Team members invited to the workspace

Lindy Role Model

Instructions

Step 1: Map Organizational Roles to Lindy Roles

Step 2: Invite Team Members

1. Go to Settings > Team in the Lindy dashboard
2. Click Invite Member
3. Enter email address
4. Select role: Owner, Editor, or Viewer
5. Confirm invitation

Pro plan: Each additional seat costs $19.99/month Enterprise plan: Custom pricing with bulk seat discounts

Step 3: Organize Agents with Folders

Use folders to organize agents by team, function, or environment:

Workspace: Acme Corp Production
├── Support/
│   ├── Email Triage Agent
│   ├── FAQ Chatbot
│   └── Escalation Agent
├── Sales/
│   ├── Lead Router
│   ├── Follow-up Agent
│   └── Meeting Scheduler
├── Operations/
│   ├── Daily Report Agent
│   ├── Monitoring Agent
│   └── Data Pipeline Agent
└── Shared/
    ├── Knowledge Base Agent
    └── Notification Agent

Folder permissions: Share folders with specific team members to control visibility. Agents in private folders are only visible to the folder owner.

Step 4: Agent Sharing Controls

Each agent can be shared independently:

Lindy Hello World

Overview

Build a minimal Lindy AI agent: Webhook Received trigger -> LLM processing -> Slack notification. Demonstrates the three core building blocks every Lindy agent uses: Trigger, Agent Step (prompt + model + skills), and Action.

Prerequisites

• Lindy account at
• Slack workspace connected (or Gmail for email variant)
• Completed lindy-install-auth setup

Instructions

Step 1: Create Agent via Dashboard

1. Click "New Agent" at
2. In the prompt field ("How can I help you?"), type:

   When I send a webhook, summarize the message and post it to Slack

1. Agent Builder auto-generates the workflow with trigger + action nodes

Step 2: Configure the Webhook Trigger

1. Click the trigger node at the top of the workflow canvas
2. Select Webhook Received
3. Copy the generated URL:

   https://public.lindy.ai/api/v1/webhooks/<unique-id>

1. Click Generate Secret — copy immediately (shown once)

Step 3: Add the Slack Action

1. Click "+" to add a step
2. Search for Slack Send Channel Message
3. Authorize your Slack workspace when prompted
4. Configure fields:

• Channel: #general (or test channel)
• Message field mode: AI Prompt
• Instruction:

     Summarize the webhook payload in one sentence.
     Payload: {{webhook_received.request.body}}

Step 4: Set the Agent Prompt

Open Settings > Prompt:

You are a webhook summarizer. When you receive a webhook payload,
extract the key information and create a concise one-sentence summary.
Be factual and specific. Do not add opinions or speculation.

Step 5: Test It

curl -X POST "https://public.lindy.ai/api/v1/webhooks/YOUR_ID" \
  -H "Authorization: Bearer YOUR_SECRET" \
  -H "Content-Type: application/json" \
  -d '{
    "event": "order.created",
    "customer": "Jane Doe",
    "amount": 149.99,
    "items": ["Widget Pro", "Adapter Cable"]
  }'

Expected Slack message: > Jane Doe placed a $149.99 order for Widget Pro and Adapter Cable.

Step 6: Verify in Dashboard

Navigate to the Tasks tab in your agent view. Confirm status shows Completed. Click into the task to see each step's input/output for debugging.

Output

The finished agent accepts th…

Lindy Incident Runbook

Overview

Incident response procedures for Lindy AI agent failures. Covers platform outages, individual agent failures, integration breakdowns, credit exhaustion, and webhook endpoint failures.

Prerequisites

• Access to the affected Lindy workspace and task history
• Ownership and escalation contacts for each affected integration
• Read access to the receiving application's health checks and sanitized logs
• A queue, manual route, or other documented fallback for critical events
• An approved location for incident receipts that excludes secrets and payloads

Instructions

1. Declare severity from customer impact and record the UTC detection time.
2. Bound the failure to the platform, one agent, an integration, credits, or the receiving endpoint before changing configuration.
3. Preserve sanitized task IDs and error evidence, then activate the smallest safe fallback that stops additional loss or duplicate actions.
4. Apply the matching playbook below and verify recovery with fresh synthetic work rather than by retrying customer data blindly.
5. Monitor the recovery window, document the outcome, and assign prevention work before resolving the incident.

Incident Severity Levels

Quick Diagnostics (First 5 Minutes)

Step 1: Check Lindy Platform Status

# Is Lindy up?
curl -s -o /dev/null -w "Lindy API: HTTP %{http_code}\n" \
  "https://public.lindy.ai" --max-time 5

# Check status page
echo "Status page: https://status.lindy.ai"

Step 2: Check Your Integration

# Is your webhook receiver up?
curl -s -o /dev/null -w "Our endpoint: HTTP %{http_code}\n" \
  "https://api.yourapp.com/health" --max-time 5

# Is the webhook auth working?
curl -s -o /dev/null -w "Webhook auth: HTTP %{http_code}\n" \
  -X POST "https://api.yourapp.com/lindy/callback" \
  -H "Authorization: Bearer $LINDY_WEBHOOK_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"test": true}' --max-time 5

Step 3: Check Credit Balance

Log in at > Settings > Billing

Lindy Install & Auth

Overview

Lindy AI is a no-code/low-code AI agent platform. Agents ("Lindies") are built in its web dashboard. This setup uses Lindy's documented webhook trigger: Lindy provides the trigger URL, and the caller authenticates with a bearer secret.

Prerequisites

• Lindy account with permission to create or edit an agent
• A secret manager for the trigger credential
• curl or another HTTP client for a synthetic connectivity check
• A non-production test payload that contains no customer data

Instructions

Step 1: Create the Webhook Trigger

1. Open the target agent in the Lindy dashboard.
2. Add a webhook trigger and copy its generated URL.
3. Store the complete URL as a secret because its unique path identifies the trigger.
4. Record only the host and a redacted path in setup receipts.

Step 2: Configure Bearer Authentication

In the webhook trigger's authentication controls, click Generate Secret and copy the Lindy-generated value into your secret manager. Store it separately from any credential used by an HTTP Request action to call your application.

# Load the copied Lindy URL and generated secret from a secret manager.
export LINDY_TRIGGER_URL="https://public.lindy.ai/api/v1/webhooks/YOUR_WEBHOOK_ID"
export LINDY_TRIGGER_SECRET="replace-with-the-lindy-generated-secret"

Callers must include that generated value as bearer authentication in every request.

Step 3: Verify Authorized Connectivity

curl --fail-with-body -X POST "$LINDY_TRIGGER_URL" \
  -H "Authorization: Bearer $LINDY_TRIGGER_SECRET" \
  -H "Content-Type: application/json" \
  -d '{"event":"setup.verify","fixture":"synthetic"}'

Confirm that exactly one task is created and retain its task ID.

Step 4: Verify Rejection Without Authentication

status="$(curl -sS -o /dev/null -w '%{http_code}' \
  -X POST "$LINDY_TRIGGER_URL" \
  -H "Content-Type: application/json" \
  -d '{"event":"setup.reject","fixture":"synthetic"}')"
case "$status" in
  2??)
    echo "unauthenticated request unexpectedly succeeded with HTTP $status" >&2
    exit 1
    ;;
  *) echo "unauthenticated request rejected with HTTP $status" ;;
esac

Any non-2xx response proves only transport rejection. Also inspect task history; do not continue if the unauthenticated request created a task.

Output

Deliver a sanitized setup receipt naming the target workspace and environment, the secret-manager references used for the trigger …

Lindy Local Dev Loop

Overview

Lindy agents run on Lindy's managed infrastructure — you do not run agents locally. Local development focuses on building and testing the webhook receivers, callback handlers, and application code that Lindy agents interact with. Use ngrok or similar tunnels to expose local endpoints for Lindy webhook triggers.

Prerequisites

• Node.js 18+ or Python 3.10+
• ngrok or Cloudflare Tunnel for HTTPS tunneling
• Lindy account with at least one agent configured
• Completed lindy-install-auth setup

Instructions

Step 1: Create Webhook Receiver

// server.ts — Express webhook receiver for Lindy callbacks
import express from 'express';
import dotenv from 'dotenv';
dotenv.config();

const app = express();
app.use(express.json());

const CALLBACK_SECRET = process.env.LINDY_CALLBACK_SECRET;
if (!CALLBACK_SECRET) {
  throw new Error('LINDY_CALLBACK_SECRET is required');
}

// Verify Lindy webhook authenticity
function verifyWebhook(req: express.Request): boolean {
  const auth = req.headers.authorization;
  return auth === `Bearer ${CALLBACK_SECRET}`;
}

// Receive Lindy agent callbacks
app.post('/lindy/callback', (req, res) => {
  if (!verifyWebhook(req)) {
    console.error('Unauthorized webhook attempt');
    return res.status(401).json({ error: 'Unauthorized' });
  }

  // Correlate the callback without logging its result or customer payload.
  const { taskId, status } = req.body;
  console.log(`Task ${taskId}: ${status}`);

  res.json({ received: true });
});

// Health check for Lindy to verify endpoint
app.get('/health', (req, res) => res.json({ status: 'ok' }));

app.listen(3000, () => console.log('Webhook receiver running on :3000'));

Step 2: Expose Local Server via Tunnel

# Install an HTTPS tunnel with your approved package-management policy, then run it.
ngrok http 3000

# Output: https://abc123.ngrok.io -> http://localhost:3000
# Use this URL in Lindy webhook configuration

Step 3: Configure Lindy Agent to Call Your Endpoint

In the Lindy dashboard, add an HTTP Request action to your agent:

• Method: POST
• URL: https://abc123.ngrok.io/lindy/callback
• Headers:
• Content-Type: application/json
• Authorization: Bearer <development callback secret>
• Body (AI Prompt mode):

  Send the task result as JSON with fields: taskId, result, status

The tunnel is the destination of the agent's HTTP Request action. A webhook trigger is the opposite dir…

Lindy Migration Deep Dive

Overview

Migrate existing automation workflows from Zapier, Make (Integromat), n8n, LangChain, or custom code to Lindy AI. Key insight: Lindy replaces rigid rule-based automations with AI agents that can reason, adapt, and handle ambiguity — so migration is a redesign opportunity, not a 1:1 translation.

Prerequisites

• Inventory of existing automations (source platform)
• Lindy workspace ready with required integrations authorized
• Migration timeline approved
• Rollback plan defined for customer-facing workflows

Migration Source Comparison

Instructions

Step 1: Inventory Source Automations

For each existing automation, document:

Step 2: Classify Migration Complexity

Step 3: Migration Strategy by Source

From Zapier:

Zapier Pattern → Lindy Pattern
────────────────────────────────
Trigger (New Email) →…

Lindy Multi-Environment Setup

Overview

Isolate Lindy AI agents across development, staging, and production using separate workspaces, dedicated API keys, and environment-specific webhook configurations. Lindy agents live in workspaces — each environment should use its own workspace to prevent cross-environment data leakage.

Prerequisites

• Multiple Lindy workspaces (one per environment) or Enterprise plan
• Secret management solution (env vars, Vault, AWS/GCP secrets)
• CI/CD pipeline with environment-aware deployment
• Application with environment detection logic

Environment Strategy

Instructions

Step 1: Create Separate Workspaces

1. Log in at
2. Create workspace for each environment: [company]-dev, [company]-staging, [company]-prod
3. Generate separate API keys in each workspace
4. Store each key in the appropriate secret store

Step 2: Environment Configuration

// config/lindy.ts — Environment-aware Lindy configuration
interface LindyConfig {
  apiKey: string;
  webhookUrl: string;
  webhookSecret: string;
  workspace: string;
  model: string;
}

function getLindyConfig(): LindyConfig {
  const env = process.env.NODE_ENV || 'development';

  const configs: Record<string, LindyConfig> = {
    development: {
      apiKey: process.env.LINDY_API_KEY_DEV!,
      webhookUrl: process.env.LINDY_WEBHOOK_URL_DEV!,
      webhookSecret: process.env.LINDY_WEBHOOK_SECRET_DEV!,
      workspace: 'dev',
      model: 'gemini-flash', // Cheap model for dev
    },
    staging: {
      apiKey: process.env.LINDY_API_KEY_STAGING!,
      webhookUrl: process.env.LINDY_WEBHOOK_URL_STAGING!,
      webhookSecret: process.env.LINDY_WEBHOOK_SECRET_STAGING!,
      workspace: 'staging',
      model: 'claude-sonnet', // Match prod model
    },
    production: {
      apiKey: process.env.LINDY_API_KEY_PROD!,
      webhookUrl: process.env.LINDY_WEBHOOK_URL_PROD!,
      webhookSecret: process.env.LINDY_WEBHOOK_SECRET_PROD!,
      workspace: 'production',
      model: 'claude-sonnet',
    },
  };

  const config = configs[env];
  if (!config) throw new Error(`Unknown environment: ${env}`);
  return config;
}

export const lindyConfig = getLindyConfig();…

Lindy Observability

Overview

Monitor workflow health from Lindy's documented task surfaces. Start with Tasks for manual inspection, then use an Agent Task Change trigger followed by Get Task Details for workflow-based monitoring and send only bounded operational fields to an external collector; task inputs, outputs, customer content, and secrets do not belong in metrics or logs.

Prerequisites

• Lindy workspace with active custom agents
• Access to each monitored agent's Tasks view
• For external monitoring: an HTTPS receiver and a metrics stack
• A distinct, nonempty callback secret stored as LINDY_CALLBACK_SECRET by the receiver and as a protected value in the Lindy HTTP Request action

Authentication and Data Boundary

Authenticate Lindy's outbound HTTP Request with a dedicated bearer value generated for the metrics receiver. Store it only in Lindy's protected action configuration and the receiver's secret manager, require at least 32 characters, compare it in constant time, and rotate it independently. Never reuse an inbound Lindy webhook secret or a metrics-scrape credential. Export only the three schema fields defined below.

Instructions

Step 1: Establish the Built-In View

1. Open the custom agent and select Tasks.
2. Review task status and open representative runs.
3. Inspect chronological steps, timestamps, conditions, and the error location.
4. Record a workspace-specific baseline by agent and workflow class. Do not copy task inputs or outputs into the baseline.

The documented sources for operational signals are:

Step 2: Build the Monitoring Workflow

Create a separate monitoring agent using documented Lindy utilities:

1. Add Agent Task Change as the trigger.
2. Select the agent and actionable events: Task succeeded, Task failed, and Task was canceled. Add created/working only when lifecycle telemetry is needed.
3. Add Get Task Details after the trigger. Leave Agent and Sub Task on Auto so Lindy associates the triggering task; set Max Number of Blocks high enough to cover the measured workflow.
4. Map the result into the small telemetry schema in Step 3.
5. Route human-readable failure alert…

Lindy Performance Tuning

Overview

Improve a Lindy workflow through controlled, workspace-specific experiments. Measure the current workflow in Tasks, preserve approval and security boundaries, change one variable, run the same sanitized fixture/eval cohort, and keep the change only when predeclared latency, quality, reliability, and cost criteria pass.

Prerequisites

• Lindy workspace with active agents
• Access to agent Tasks tab (view step-by-step execution history)
• A representative, data-minimized fixture set and offline eval cohort
• Permission to inspect Tasks and restore a saved version
• An owner-approved list of invariants: confirmations, authorization, redaction, retention, and side-effect limits

Instructions

Step 1: Define the Experiment Contract

Before editing, record:

• one workflow class and representative sanitized fixtures;
• the exact variable to change and why it should help;
• baseline sample window and sample count;
• duration median/p95, outcome ratio, eval score, and workspace-reported usage/cost;
• acceptance and rollback thresholds; and
• security/approval invariants that must remain unchanged.

Use the Tasks view and Get Task Details to identify the slowest or least reliable block. Do not infer universal latency or credit values from this skill.

Step 2: Save a Rollback Point

Open Version History and identify the last known-good version. Record its timestamp or label. Restoring a version creates a new editable version; it does not erase the current history. Keep production activation and side-effecting actions unchanged until the candidate passes the evaluation lane.

Step 3: Choose One Variable

Prioritize the measured bottleneck:

Do not remove confirmation, authorization, validation, redaction, audit, or fallback steps mer…

Lindy Production Checklist

Overview

Create an evidence-backed go/no-go decision for a Lindy agent. Treat the Lindy dashboard and the organization's current contract, workspace configuration, and runbooks as the authorities. Do not infer product entitlements, prices, quotas, security features, support terms, or compliance commitments from this skill.

Use Read to inspect configuration and evidence, Write or Edit to maintain the readiness record, and Bash(curl:*) only for an approved synthetic webhook probe. Never place a secret in the record or command output.

Prerequisites

• Access to the target Lindy workspace and its Tasks view.
• An exported webhook-trigger URL and its nonempty Lindy-generated trigger secret.
• A separate, nonempty callback secret when a Lindy HTTP Request action calls your application. Never reuse the trigger secret as the callback secret.
• A synthetic test case with no production personal or confidential data and a unique correlation ID.
• Access to current contract/workspace evidence for any claim about pricing, credits, thresholds, secret rotation, SSO, SCIM, support, or a BAA.
• A durable queue when callback work cannot be completed safely within the receiver's synchronous response window.

Instructions

1. Open an evidence record

Record the workspace, agent, reviewer, date, release identifier, and links to artifacts. Give every check one of three verdicts: PASS, FAIL, or NOT VERIFIED. A missing entitlement or policy document is NOT VERIFIED, not an assumed pass.

2. Verify the two authentication boundaries

For an application calling a Lindy webhook trigger:

• Confirm the URL uses HTTPS and its hostname is exactly public.lindy.ai.
• Confirm the authorization value is the secret generated for that trigger.
• Keep the URL and trigger secret in an approved secret manager; redact both from screenshots, logs, tickets, and readiness reports.

For a Lindy HTTP Request action calling your application:

• Generate and store an independent LINDY_CALLBACK_SECRET in your application.
• Configure the action to send Authorization: Bearer <callback-secret>.
• Reject a missing or mismatched value before accepting or acting on the body.
• Apply a bounded schema and payload-size limit before enqueueing work.

Lindy documents the trigger-side generated secret and configurable headers for HTTP Request actions. It does not make one secret interchangeable across both directions.

3. Prove a real synthetic task is created

Run a probe only after the URL and secret checks pass:

set -euo pipefail

…

Lindy Rate Limits and Credits

Overview

Build application-side controls for Lindy webhook-trigger traffic and workspace usage. Lindy plan terms, prices, credit rules, and service limits can vary or change; obtain them from the current workspace and contract instead of copying fixed commercial numbers into code.

Use Read to inspect the caller and Write or Edit to implement its policy. This skill does not assume an undocumented Lindy REST API or SDK.

Prerequisites

• The exact webhook URL generated by the target Lindy trigger.
• A nonempty secret generated for that trigger and stored in a secret manager.
• Current workspace or contract evidence for credits, quotas, and entitlements.
• A shared atomic store for admission control and idempotency when more than one process or instance can send triggers.
• A durable queue with dead-letter handling for work that may need retries.
• An approved bounded payload schema and a synthetic, non-sensitive test case.

Instructions

Step 1: Establish current limits and a local safety policy

Record the evidence source and review date for every Lindy-provided credit or service constraint. Then choose application-owned controls independently:

• maximum admitted events per tenant and workload;
• maximum queue depth and age;
• maximum serialized payload size;
• retry count and total retry deadline;
• concurrency per worker pool; and
• warning, shedding, and stop thresholds.

These are local risk controls, not claims about Lindy's service limits. Review them from observed traffic, task outcomes, and the organization's budget.

Step 2: Fail closed before attaching the trigger secret

Parse the configured URL; require protocol https:, hostname exactly public.lindy.ai, no username or password, and the expected webhook path. Reject an empty trigger secret. Never send the trigger secret to a callback receiver or reuse a callback secret for the outbound trigger.

const triggerUrl = new URL(process.env.LINDY_TRIGGER_URL ?? '');
const triggerSecret = process.env.LINDY_TRIGGER_SECRET ?? '';

if (
  triggerUrl.protocol !== 'https:' ||
  triggerUrl.hostname !== 'public.lindy.ai' ||
  triggerUrl.username !== '' ||
  triggerUrl.password !== '' ||
  !triggerUrl.pathname.startsWith('/api/v1/webhooks/')
) {
  throw new Error('Refusing to send a trigger secret outside the expected Lindy webhook URL');
}
if (triggerSecret.length === 0) throw new Error('LINDY_TRIGGER_SECRET is required');

Step 3: Validate and deduplicate before enqueue

Allow only documented fields, types, lengths, and enumerated values. Reject unknown fields and payload…

Lindy Reference Architecture

Overview

Choose an integration shape for Lindy workflows without inventing a public SDK or control-plane API. The supported application boundary in these patterns is a dashboard-created Lindy webhook trigger, optionally paired with Lindy's HTTP Request or callback action for outbound delivery.

Prerequisites

• Understanding of Lindy agent model (triggers, actions, skills)
• Familiarity with webhook-based architectures
• Production requirements defined (throughput, latency, reliability)
• Current workspace evidence for the triggers, actions, integrations, and plan entitlements you intend to use
• A separate secret for each Lindy trigger and a different secret for each callback receiver; neither belongs in source control or architecture diagrams

Instructions

1. Write the workload's trust boundaries before selecting a pattern: event producers, Lindy trigger, callback receiver, stores, operators, and third parties.
2. Record data classification, maximum payload size, expected event rate, recovery objective, and whether duplicate delivery is safe.
3. Select the smallest pattern below that meets those requirements. Treat product features as available only after verifying them in the current Lindy workspace.
4. For every webhook edge, require HTTPS, an exact approved hostname, a per-edge secret, schema validation, payload bounds, idempotency, bounded retry, and a dead-letter or manual recovery path.
5. Test authorized and unauthorized requests with synthetic data. A 2xx response is insufficient evidence unless the expected task or durable queue record exists.
6. Produce the architecture decision record and dataflow inventory described in Output, then have a security reviewer approve the exact deployment revision.

Trust-Boundary Contract

• A Lindy trigger URL is created in the dashboard and uses the documented https://public.lindy.ai/api/v1/webhooks/... shape. Validate https: and the exact public.lindy.ai hostname before attaching its Lindy-generated trigger secret.
• Authenticate your own event ingress independently. Do not reuse a Lindy trigger secret to protect your application or callback endpoint.
• Minimize and redact event data before enqueueing it. Do not forward credentials, session tokens, raw customer records, or unrestricted third-party webhook bodies.
• Acknowledge external events only after a durable, idempotent queue write. Check the Lindy response before marking delivery successful, and retry only transient failures with a strict attempt and elapsed-time budget.
• Installed skills and local configuration are consumers of this design; they are not publication sources and must never upload secrets or runtime state.

Architecture 1: Simple Webhook Integra…

Lindy Integration Patterns

Overview

Use Lindy's documented integration primitives: Webhook Received for inbound calls, HTTP Request for outbound calls, Run Code for bounded transformations, and Send POST Request to Callback for the documented callback workflow. This is not an SDK guide: Lindy's current public documentation does not provide the package, client, agent CRUD, streaming, API key, or general API-host surface that older copies of this skill claimed.

Prerequisites

• Lindy workspace with an editable custom agent
• An application-owned HTTPS endpoint when outbound calls or callbacks are required
• A secret manager for the Lindy-generated Webhook Received secret and any separate credential owned by the target application
• Sanitized test fixtures and access to Tasks/Test Panel

Authentication and Trust Boundaries

• Inbound to Lindy: create the webhook in the Webhook Received trigger, select Generate Secret, store the one-time value, and send it as an Authorization bearer value. Use only the generated public.lindy.ai webhook URL.
• Outbound from Lindy: configure authentication required by the target service in the HTTP Request action. This is the target service's credential, not a Lindy API key.
• Callback: Lindy's webhook guide documents callbackUrl and Send POST Request to Callback, but does not document a Lindy callback signature. Treat callback content as untrusted unless the receiving application establishes its own authenticated boundary; never invent or claim a Lindy signing header.
• Keep inbound, outbound, and callback credentials distinct. Never put secrets in a prompt, body, query string, task title, log, or Run Code text output.

Instructions

1. Configure an Inbound Webhook Received Trigger

1. Add Webhook Received and create a named webhook.
2. Generate its secret and store it immediately; Lindy documents that it is shown once.
3. Choose follow-up behavior deliberately: same task, new task, or ignore.
4. Define a minimal request schema and reject oversized/unknown fields in the calling application before sending.
5. Send a sanitized fixture, then verify the new task in Tasks.

This is a small application wrapper around the documented webhook, not a Lindy SDK:

type Intake = { event: 'document.ready'; documentRef: string };

async function triggerLindyWebhook(input: {
  webhookUrl: string;
  webhookSecret: string;
  payload: Intake;
}): Promise<number> {
  const url = new URL(input.webhookUrl);
  if (
    url.protocol !== 'https:' ||
    url.hostname !== 'public.lindy.ai…

Lindy Security Basics

Overview

Secure Lindy workflows at the boundaries Lindy currently documents: generated Webhook Received secrets, per-action connected-account selection, target-service authentication in HTTP Request, Ask for Confirmation/draft modes, dedicated Computer Use sessions, Tasks, and Test Panel. Do not rely on an undocumented Lindy API key, webhook signature, role, connection-sharing level, fixed quota, or plan entitlement.

Prerequisites

• Lindy workspace with an editable custom agent
• Inventory of triggers, actions, connected accounts, external endpoints, data classes, owners, and consequential side effects
• Sanitized fixtures and test/sandbox integrations

Instructions

Step 1: Draw the Trust Map

For every path, record source, destination, data fields, credential owner, selected connected account, allowed side effects, approver, failure path, and evidence source. Separate these directions:

Step 2: Secure Webhook Received

1. Create the webhook inside the Webhook Received trigger.
2. Generate the secret, copy it once, and store it in the caller's secret manager.
3. Send it only in the Authorization bearer header to the generated HTTPS URL.
4. Keep the webhook URL/secret out of prompts, bodies, query strings, task titles, screenshots, logs, and tickets.
5. Minimize and validate the caller's payload before transmission.
6. Rotate after suspected exposure by creating/reconfiguring the protected boundary, verifying the replacement, and retiring the old value according to the current UI.

The bearer secret authenticates the caller to Lindy. It does not authenticate a callback from Lindy to your application, and Lindy's Webhooks guide does not document an HMAC signature or timestamp header for that callback.

Step 3: Scope Connected Accounts and Actions

Lindy documents that each action selects one connected account. For every action:

• select the account with the minimum data and authority required;
• prefer a dedicated work/test account when the integration supports one;
• remove actions and connections no longer required by the workflow;
• avoid combining broad read and consequential write abilities in an autonomous Agent Step when deterministic actions/conditions are suf…

Lindy Upgrade and Migration

Overview

Plan and verify changes to Lindy workflows through the documented workspace UI. Use Lindy's Version History as the in-place restoration mechanism, the Test Panel for controlled execution, and the Tasks view for run evidence. Do not invent a Lindy SDK, API key, package upgrade, CLI, export endpoint, or control plane.

Use Read to inspect the approved change record and evidence. Use Write or Edit to maintain the migration record without copying secrets or customer data.

Prerequisites

• Authorized access to every source and target workspace in scope.
• A named change owner, approver, rollback owner, and acceptance owner.
• A known-good saved agent version visible in Version History.
• A current inventory of triggers, actions, conditions, integrations, knowledge sources, manual approval steps, owners, and downstream side effects.
• Synthetic inputs and sandboxed destinations for Test Panel runs; its tests can execute real actions and call real external systems.
• Baseline task receipts from the Tasks view and explicit acceptance criteria.
• Current Lindy documentation and workspace evidence for any transfer or feature behavior relied upon by the change.

Instructions

Step 1: Define the change boundary

Record whether this is an in-place configuration change, restoration, template- based recreation, or workspace move. List the exact workflows, integrations, callers, secrets, data stores, approvers, and external side effects in scope.

Treat anything not documented by Lindy or directly observed in the target workspace as NOT VERIFIED. Templates are starting workflows that must be configured, customized, and tested; do not assume they preserve credentials, triggers, knowledge, memories, phone or mail resources, permissions, approval rules, webhook URLs, or other workspace-bound state.

Step 2: Capture a rollback anchor and baseline

1. Save the current working workflow with a descriptive version name.
2. Open Version History, record the rollback version and review its changes.
3. Run approved synthetic cases and retain Tasks-view identifiers, step outcomes, and expected side effects.
4. Record current integration identities, trigger configuration, manual approval gates, and sanitized destination identifiers.

Do not copy OAuth tokens, webhook secrets, full payloads, or customer content into the record.

Step 3: Build the candidate safely

For an in-place change, edit the workflow but keep it inactive or otherwise isolated until testing and approval are complete. For a workspace move, use a documented template installation or recreate the workflow in the target workspace, then verify every target-bound dependency individually.

If the targe…

Lindy Webhooks and Events

Overview

Build two documented boundaries: an application calls a Lindy Webhook Received trigger using its generated Bearer secret, and Lindy calls an application through an outbound callback action such as HTTP Request. Treat them as separate trust directions with separate secrets, schemas, retry policies, and evidence.

Use Read to inspect the integration and Write or Edit to implement its closed contracts. Implement only the documented generated-Bearer trigger and configurable outbound-request surfaces; do not add unaudited control-plane, registration, event-feed, or signature mechanisms.

Prerequisites

• A Webhook Received trigger with its generated URL and nonempty generated secret.
• An approved secret manager; never store secret values in code or skill output.
• A separate, nonempty application-owned callback secret.
• A fixed or strictly allowlisted HTTPS callback destination controlled by the application owner.
• Closed request and callback schemas with local field, length, enum, and byte limits.
• A shared atomic idempotency store and durable queue for scaled or retryable work.
• Access to Lindy's Tasks view and synthetic test data with unique request IDs.

Instructions

Step 1: Define minimal contracts

Specify only fields the workflow needs. A safe application-owned trigger envelope might contain requestId, an enumerated eventType, a non-sensitive subjectId, and occurredAt. Reject unknown fields, invalid types, excessive lengths, and payloads above the documented local byte limit before enqueue or transmission.

Define the callback separately—for example requestId, taskId, and an enumerated status. Do not return full prompts, model output, source records, or customer data unless an approved data contract requires those fields.

Step 2: Configure the Lindy trigger

In the workflow, add Webhook Received, create or select a webhook, generate its secret, and store that secret immediately. Lindy documents URLs in this form:

https://public.lindy.ai/api/v1/webhooks/[unique-id]

Callers send Authorization: Bearer [generated-secret]. Select the documented follow-up behavior that matches the workflow: handle in the same task, create a new task, or ignore follow-ups. Treat request body, headers, and query parameters as untrusted input. Never copy the full headers object into a prompt or log because it can contain the Authorization secret.

Step 3: Validate before attaching the trigger secret

Fail startup unless the URL uses HTTPS, has hostname exactly public.lindy.ai, no unexpected port or embedded c…