Complete Lindy integration skill pack with 24 skills covering AI assistants, task automation, workflows, and intelligent automation. Flagship tier vendor pack.

24 plugin-local skills

MIT License

Claude Code Adapters (declared)

Installation

Open Claude Code and run this command:

/plugin install lindy-pack@claude-code-plugins-plus

Use --global to install for all projects, or --project for current project only.

What It Does

> 24 enterprise-grade skills for building, integrating, and operating Lindy AI agents — the no-code AI automation platform with 7,000+ integrations.

Skills (24) plugin-local skills

lindy-ci-integration View full skill →

Configure CI/CD pipelines for testing Lindy AI agent integrations.

ReadWriteEditBash(gh:*)Bash(npm:*)

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}`)
      .set('Cont


                
                  
                  lindy-common-errors
                  View full skill →
                
                
                  Troubleshoot common Lindy AI agent errors and workflow failures.
                  
                      ReadWriteEditBash(curl:*)Grep
                    
                
                
                  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

Capture the failing run identifier, trigger payload shape, and first failing step without copying sensitive fields into the incident record.
Reproduce the behavior in a test agent or disabled workflow using a bounded input.
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:

Cause
Diagnostic
Fix


Wrong URL
Check webhook URL in agent config
Copy exact URL from trigger settings


Missing auth
curl -v shows 401
Add Authorization: Bearer <secret> header


Agent inactive
Dashboard shows agent paused
Activate the agent


Filter blocking
Trigger filter too restrictive
Review filter conditions, test with broader filter


Wrong HTTP method
Using GET instead of POST
Lindy webhooks require POST



# 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:

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

Schedule Trigger Missed
Symptoms: Agent did not run at scheduled time Solutions:

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

Action Errors
Slack Send Failed

                
                  
                  lindy-core-workflow-a
                  View full skill →
                
                
                  Build and configure multi-step Lindy AI agent workflows.
                  
                      ReadWriteEditBash(curl:*)
                    
                
                
                  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):

Click New Agent at
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


Agent Builder auto-generates trigger + action nodes

Option B — Manual Build:

Click New Agent > Start from scratch
Add trigger: Click "+" > Select trigger type
Add actions: Click "+" > Search for action
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)

Click "+" > Condition
Write natural lan
                
              

                
                  
                  lindy-core-workflow-b
                  View full skill →
                
                
                  Configure Lindy triggers, scheduling, multi-agent delegation, and automation.
                  
                      ReadWriteEditBash(curl:*)
                    
                
                
                  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:

Create first trigger (e.g., Webhook Received)
Click "New Trigger" to add a second (e.g., Email Received)
Connect grey arrows from both triggers to the first action step
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):

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

Step 5: Calendar Event Trigger
For meeting-related automation:

Add trigger > Calendar Event Start
Set Minutes Offset:


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


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 Message
[Meeting

                

              

                
                  
                  lindy-cost-tuning
                  View full skill →
                
                
                  Optimize Lindy AI costs through credit management, model selection, and agent consolidation.
                  
                      ReadWriteEdit
                    
                
                
                  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

Error
Cause
Fix

                
              

Factor
Credits


Basic model task (Gemini Flash)
1-2


Mid-tier model (GPT-4o-mini, Claude Haiku)
2-5


Large model task (GPT-4, Claude Sonnet)
5-10


Premium model (Claude Opus)
~10+


Phone call (US/Canada)
~20/minute


Phone call (international)
21-53/minute


Premium actions (webhooks)
Additional per action


Minimum per task
1 credit


Plan Costs

Plan
Monthly
Credits
Per Extra Seat


Free
$0
400
N/A


Pro
$49.99
5,000
$19.99


Business
$299.99
30,000
Included


Enterprise
Custom
Custom
Custom


Instructions
Step 1: Audit Agent Credit Consumption
For each active agent, collect:

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

Create a cost audit table:

Agent
Tasks/Month
Credits/Task
Model
Monthly Credits
% of Total


Support Bot
500
5
Claude Sonnet
2,500
50%


Lead Router
200
2
GPT-4o-mini
400
8%


Report Gen
30
10
GPT-4
300
6%


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?"

Current Setup
Optimized
Savings


Email classify with Claude Sonnet (5 cr)
Gemini Flash (1 cr)
80%


Data extract with GPT-4 (10 cr)
GPT-4o-mini (3 cr)
70%


Simple routing with Cla
                
              
                
                  
                  lindy-data-handling
                  View full skill →
                
                
                  Data handling best practices for Lindy AI agents.
                  
                      ReadWriteEdit
                    
                
                
                  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

Component
Data Storage
Retention


Tasks
Task inputs, outputs, step data
Visible in dashboard


Memory
Persistent snippets across tasks
Until manually deleted


Context
Per-task accumulated context
Task lifetime only


Knowledge Base
Uploaded files, crawled sites
Until manually removed


Integrations
OAuth tokens, connection data
Until disconnected


Computer Use
Browser session, screenshots
30 days after last use


Instructions
Step 1: Classify Data in Agent Workflows
Map what data each agent processes:

Data Category
Examples
Handling


Public
Product info, FAQs, pricing
No restrictions


Internal
Sales reports, meeting notes
Limit to authorized agents


Confidential
Customer emails, CRM data
Access controls + audit


Restricted
PII, PHI, payment data
Minimize exposure + compliance


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:

Customer databases
                
              

                
                  
                  lindy-debug-bundle
                  View full skill →
                
                
                  Comprehensive debugging toolkit for Lindy AI agents.
                  
                      ReadWriteEditBash(curl:*)Grep
                    
                
                
                  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:

Navigate to the failing agent
Open the Tasks tab
Filter by Failed status
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


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

Step 4: Check Integration Health

# Test outbound connectivity to common Lindy integration t

                

              

                
                  
                  lindy-deploy-integration
                  View full skill →
                
                
                  Deploy applications that integrate with Lindy AI agents.
                  
                      ReadWriteEditBash(gh:*)Bash(docker:*)Bash(npm:*)
                    
                
                
                  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 Lind
                
              

                
                  
                  lindy-enterprise-rbac
                  View full skill →
                
                
                  Configure enterprise role-based access control for Lindy AI workspaces.
                  
                      ReadWriteEdit
                    
                
                
                  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

Role
Create Agents
Edit Agents
Run Agents
View Tasks
Manage Team


Owner
Yes
Yes
Yes
Yes
Yes


Editor
Yes
Yes
Yes
Yes
No


Viewer
No
No
No
Yes
No


Instructions
Step 1: Map Organizational Roles to Lindy Roles

Org Role
Lindy Role
Rationale


Engineering Lead
Owner
Full workspace control


Developer
Editor
Build and modify agents


Ops/Support
Editor
Run agents and configure workflows


Manager
Viewer
Monitor task execution and metrics


Stakeholder
Viewer
Read-only access to results


Step 2: Invite Team Members

Go to Settings > Team in the Lindy dashboard
Click Invite Member
Enter email address
Select role: Owner, Editor, or Viewer
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
                  View full skill →
                
                
                  Create your first Lindy AI agent with a real trigger and action.
                  
                      ReadWriteEditBash(curl:*)
                    
                
                
                  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

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


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


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

Step 2: Configure the Webhook Trigger

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


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


Click Generate Secret — copy immediately (shown once)

Step 3: Add the Slack Action

Click "+" to add a step
Search for Slack Send Channel Message
Authorize your Slack workspace when prompted
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 the tes
                
              

                
                  
                  lindy-incident-runbook
                  View full skill →
                
                
                  Incident response procedures for Lindy AI agent failures and outages.
                  
                      ReadWriteEditBash(curl:*)
                    
                
                
                  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

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

Incident Severity Levels

Sharing Level
Who Gets It
What They Can Do


Edit access

                
              

Severity
Description
Response Time
Examples


SEV1
All agents failing, customer impact
15 minutes
Lindy platform outage, all webhooks failing


SEV2
Critical agent down
30 minutes
Support bot offline, phone agent unreachable


SEV3
Degraded performance
2 hours
High latency, intermittent failures


SEV4
Minor issue
24 hours
Non-critical agent misconfigured


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
                  View full skill →
                
                
                  Set up a Lindy account and authenticated webhook trigger.
                  
                      ReadWriteEditBash(curl:*)
                    
                
                
                  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

Open the target agent in the Lindy dashboard.
Add a webhook trigger and copy its generated URL.
Store the complete URL as a secret because its unique path identifies the trigger.
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 and c
                
              

                
                  
                  lindy-local-dev-loop
                  View full skill →
                
                
                  Set up local development workflow for testing Lindy AI agent integrations.
                  
                      ReadWriteEditBash(npm:*)Bash(node:*)Bash(npx:*)
                    
                
                
                  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 directio
                
              

                
                  
                  lindy-migration-deep-dive
                  View full skill →
                
                
                  Advanced migration strategies for moving to Lindy AI from other platforms.
                  
                      ReadWriteEditBash(curl:*)
                    
                
                
                  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

Source Platform
Lindy Equivalent
Key Difference


Zapier Zap
Lindy Agent
AI reasoning replaces rigid if/then


Make Scenario
Lindy Agent
No-code builder instead of module chains


n8n Workflow
Lindy Agent
Managed infra, no self-hosting


LangChain Agent
Lindy Agent Step
No-code, managed, no Python needed


Custom code
HTTP Request + Run Code
Less code, AI fills gaps


Instructions
Step 1: Inventory Source Automations
For each existing automation, document:

Field
Example


Name
Support Email Triage


Trigger
New email in support@co.com


Steps
1. Parse email 2. Classify 3. Route to channel


Integrations
Gmail, Slack, Sheets


Frequency
~50 runs/day


Complexity
Medium (3 steps, 1 condition)


Step 2: Classify Migration Complexity

Complexity
Criteria
Migration Approach
Time


Simple
1-3 steps, no conditions
Build from scratch in Lindy
30 min


Medium
4-8 steps, conditions
Natural language description to Agent Builder
1-2 hours


Complex
9+ steps, multi-branch, loops
Redesign as multi-agent society
1-2 days


Custom code
Python/JS logic
Run Code action + HTTP Request
2-4 hours


Step 3: Migration Strategy by Source
From Zapier:

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

                

              

                
                  
                  lindy-multi-env-setup
                  View full skill →
                
                
                  Configure Lindy AI across development, staging, and production environments.
                  
                      ReadWriteEditBash(aws:*)Bash(gcloud:*)Bash(vault:*)
                    
                
                
                  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

Environment
Workspace
API Key Source
Agent Config


Development
dev-workspace
.env.local
Debug prompts, test integrations


Staging
staging-workspace
CI/CD secrets
Production-like, test data


Production
prod-workspace
Secret manager
Hardened prompts, live integrations


Instructions
Step 1: Create Separate Workspaces

Log in at
Create workspace for each environment: [company]-dev, [company]-staging, [company]-prod
Generate separate API keys in each workspace
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
                  View full skill →
                
                
                  Monitor Lindy AI agent health, task success rates, and credit consumption.
                  
                      ReadWriteEdit
                    
                
                
                  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

Open the custom agent and select Tasks.
Review task status and open representative runs.
Inspect chronological steps, timestamps, conditions, and the error location.
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:

Signal
Source
Handling


Task outcome and frequency
Tasks / Agent Task Change
Aggregate by configured agent key


Duration and failing block
Get Task Details
Retain duration; keep block content in Lindy


Workspace spend
Lindy billing view
Keep billing data at its documented source


Step 2: Build the Monitoring Workflow
Create a separate monitoring agent using documented Lindy utilities:

Add Agent Task Change as the trigger.
Select the agent and actionable events: Task succeeded, Task failed, and Task was canceled. Add created/working only when lifecycle telemetry is needed.
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.
Map the result into the small telemetry schema in Step 3.
Route human-readable failure alerts inside Li
                
              

                
                  
                  lindy-performance-tuning
                  View full skill →
                
                
                  Optimize Lindy AI agent execution speed, reliability, and cost efficiency.
                  
                      ReadWriteEdit
                    
                
                
                  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:

Bottleneck
Symptom
Fix


AI step dominates duration/usage
One step is the measured hotspot
Compare one available model/configuration while holding prompt/tools fixed


Repeated reasoning steps
Same context is processed repeatedly
Test a single structured step while preserving required checks


Broad autonomous scope
Variable paths or tool calls
Narrow skills and define measurable exit conditions


Knowledge retrieval dominates
Too many/large results
Reduce result scope while measuring answer quality


Independent list work is sequential
Per-item waiting dominates
Test a bounded loop and respect downstream rate limits


Trigger volume is noisy
Many irrelevant tasks
Add a precise trigger filter and verify recall


Do not remove confirmation, authorization, validation, redaction, audit, or fallback steps merely t
                
              

                
                  
                  lindy-prod-checklist
                  View full skill →
                
                
                  Production readiness checklist for Lindy AI agent deployments.
                  
                      ReadWriteEditBash(curl:*)
                    
                
                
                  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

: "${LIND

                

              

                
                  
                  lindy-rate-limits
                  View full skill →
                
                
                  Manage Lindy AI credits, rate limits, and usage optimization.
                  
                      ReadWriteEdit
                    
                
                
                  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 payloads abo
                
              

                
                  
                  lindy-reference-architecture
                  View full skill →
                
                
                  Reference architectures for Lindy AI agent integrations.
                  
                      ReadWriteEdit
                    
                
                
                  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

Write the workload's trust boundaries before selecting a pattern: event producers, Lindy trigger, callback receiver, stores, operators, and third parties.
Record data classification, maximum payload size, expected event rate, recovery objective, and whether duplicate delivery is safe.
Select the smallest pattern below that meets those requirements. Treat product features as available only after verifying them in the current Lindy workspace.
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.
Test authorized and unauthorized requests with synthetic data. A 2xx response is insufficient evidence unless the expected task or durable queue record exists.
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 Integration
                
              

                
                  
                  lindy-sdk-patterns
                  View full skill →
                
                
                  Lindy integration patterns for webhook handling, HTTP actions, and Run Code.
                  
                      ReadWriteEdit
                    
                
                
                  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

Add Webhook Received and create a named webhook.
Generate its secret and store it immediately; Lindy documents that it is shown once.
Choose follow-up behavior deliberately: same task, new task, or ignore.
Define a minimal request schema and reject oversized/unknown fields in the calling application before sending.
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' ||
    !url

                

              

                
                  
                  lindy-security-basics
                  View full skill →
                
                
                  Implement security best practices for Lindy agents and integrations.
                  
                      ReadWriteEdit
                    
                
                
                  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:

Direction
Supported boundary


Application to Lindy
Webhook Received URL + Lindy-generated bearer secret


Lindy to external service
HTTP Request + that service's authentication


External account action
Exactly the connected account selected on the action


Lindy callback to application
Receiver-owned trust boundary; no documented Lindy signature claim


Step 2: Secure Webhook Received

Create the webhook inside the Webhook Received trigger.
Generate the secret, copy it once, and store it in the caller's secret manager.
Send it only in the Authorization bearer header to the generated HTTPS URL.
Keep the webhook URL/secret out of prompts, bodies, query strings, task titles, screenshots, logs, and tickets.
Minimize and validate the caller's payload before transmission.
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 sufficient; an
                
              

                
                  
                  lindy-upgrade-migration
                  View full skill →
                
                
                  Manage Lindy agent configuration changes, platform updates, and migrations.
                  
                      ReadWriteEdit
                    
                
                
                  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

Save the current working workflow with a descriptive version name.
Open Version History, record the rollback version and review its changes.
Run approved synthetic cases and retain Tasks-view identifiers, step outcomes, and expected side effects.
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 target use
                
              

                
                  
                  lindy-webhooks-events
                  View full skill →
                
                
                  Configure Lindy AI webhook triggers, callback patterns, and event handling.
                  
                      ReadWriteEdit
                    
                
                
                  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 creden
                
              

          

        

      
      

      
      

      
      

      
      
  Ready to use lindy-pack?
  
    
    
  




      
      
          Related Plugins
          
            
  supabase-pack
  Complete Supabase integration skill pack with 30 skills covering authentication, database, storage, realtime, edge functions, and production operations. Flagship+ tier vendor pack.
  /plugin install supabase-pack@claude-code-plugins-plus
  

  vercel-pack
  Complete Vercel integration skill pack with 30 skills covering deployments, edge functions, preview environments, performance optimization, and production operations. Flagship+ tier vendor pack.
  /plugin install vercel-pack@claude-code-plugins-plus
  

  clay-pack
  Complete Clay integration skill pack with 30 skills covering data enrichment, waterfall workflows, AI agents, and GTM automation. Flagship+ tier vendor pack.
  /plugin install clay-pack@claude-code-plugins-plus
  

  cursor-pack
  Complete Cursor integration skill pack with 30 skills covering AI code editing, composer workflows, codebase indexing, and productivity features. Flagship+ tier vendor pack.
  /plugin install cursor-pack@claude-code-plugins-plus
  

  exa-pack
  Complete Exa integration skill pack with 30 skills covering neural search, semantic retrieval, web search API, and AI-powered discovery. Flagship+ tier vendor pack.
  /plugin install exa-pack@claude-code-plugins-plus
  

  firecrawl-pack
  Complete Firecrawl integration skill pack with 30 skills covering web scraping, crawling, markdown conversion, and LLM-ready data extraction. Flagship+ tier vendor pack.
  /plugin install firecrawl-pack@claude-code-plugins-plus
  

          
        

      
      
          Tags
          
            lindyai-assistantautomationworkflowstasksintelligent-automation
          
        
    
  

  

    

    
    
        
            
                Agent Skills in Your Inbox
                
                    
                    
                    
                
                No spam, ever. Unsubscribe with one click.
            

            
                
                    Product
                    
                        Explore
                        Skills
                        Cowork
                        Compare
                        Tools
                    
                
                
                    Resources
                    
                        Docs
                        Changelog
                        Collections
                        Playbooks
                        Research
                        Learning
                    
                
                
                    Company
                    
                        Community
                        Hall of Fame
                        GitHub
                    
                
                
                    Legal
                    
                        Privacy
                        Terms
                        Acceptable Use
                    
                
            

            
            

            
                Tons of Skills by Intent Solutions. Open-source plugins, agents and skills for AI coding agents.
                © 2026 Tons of Skills | Intent Solutions

Cause	Diagnostic	Fix
Wrong URL	Check webhook URL in agent config	Copy exact URL from trigger settings
Missing auth	`curl -v` shows 401	Add `Authorization: Bearer <secret>` header
Agent inactive	Dashboard shows agent paused	Activate the agent
Filter blocking	Trigger filter too restrictive	Review filter conditions, test with broader filter
Wrong HTTP method	Using GET instead of POST	Lindy webhooks require POST

Factor	Credits
Basic model task (Gemini Flash)	1-2
Mid-tier model (GPT-4o-mini, Claude Haiku)	2-5
Large model task (GPT-4, Claude Sonnet)	5-10
Premium model (Claude Opus)	~10+
Phone call (US/Canada)	~20/minute
Phone call (international)	21-53/minute
Premium actions (webhooks)	Additional per action
Minimum per task	1 credit

Plan	Monthly	Credits	Per Extra Seat
Free	$0	400	N/A
Pro	$49.99	5,000	$19.99
Business	$299.99	30,000	Included
Enterprise	Custom	Custom	Custom

Agent	Tasks/Month	Credits/Task	Model	Monthly Credits	% of Total
Support Bot	500	5	Claude Sonnet	2,500	50%
Lead Router	200	2	GPT-4o-mini	400	8%
Report Gen	30	10	GPT-4	300	6%