Connect Directus to Any Service with Stacker PIPEs - No Scripts Required

What You'll Build

A reusable data pipeline that fetches content from Directus, transforms it with JSONPath field mapping, and delivers it to any HTTP endpoint - all managed with three CLI commands. No curl scripts, no cron jobs, no custom code.

Directus as a data source (headless CMS)
Any HTTP endpoint as a target (Chatwoot, Slack, CRMs, webhooks)
JSONPath-based field transformation
Auth header support for protected APIs

Quick Answer

# 1. Activate the pipe
stacker pipe activate <PIPE_ID> \
  --source-url "http://directus:8055/items/pages" \
  --trigger manual \
  --target-header "Authorization: Bearer <TOKEN>"

# 2. Trigger data transfer
stacker pipe trigger <PIPE_ID> --json

# 3. List active pipes
stacker pipe list --json

Three commands. Data flows from Directus to any HTTP endpoint.

Why Use Stacker PIPEs Instead of Custom Scripts?

Every SaaS product eventually faces the same problem: data trapped in one system needs to reach another. Directus holds your content. Chatwoot handles your conversations. Slack gets your notifications. Each has an API. Each needs data from the others.

The traditional approach requires writing a bash script with curl -X POST, parsing JSON with jq, handling auth tokens, scheduling with cron, and fixing it when it breaks. Every integration becomes a fragile snowflake.

Stacker PIPEs replace all of that with a composable, reusable data connection. Define the source, target, and mapping once - then trigger it with a single command.

Prerequisites

Stacker CLI installed (cargo install stacker-cli)
A deployed Stacker project with Directus running
An agent registered and connected to the dashboard

# Verify agent is connected
stacker agent health --deployment <DEPLOYMENT_HASH>

Step 1: Create the Pipe Instance

Create a pipe instance through the Stacker API or dashboard. This registers the pipe in the Stacker database and returns a unique pipe_instance_id.

curl -X POST "https://stacker.try.direct/api/v1/pipes/instances" \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer <TOKEN>" \
  -d '{
    "name": "directus-to-webhook",
    "source_type": "http",
    "target_type": "http"
  }'

Step 2: Activate the Pipe on the Agent

Activation tells the agent where to fetch data from and where to send it. The agent handles HTTP requests across Docker networks, auth headers, JSONPath transformation, and error reporting.

stacker pipe activate <PIPE_INSTANCE_ID> \
  --source-url "http://project-directus-1:8055/items/pages" \
  --trigger manual \
  --target-header "Authorization: Bearer <YOUR_TOKEN>" \
  --deployment <DEPLOYMENT_HASH>

Verify the pipe is active:

stacker pipe list --json --deployment <DEPLOYMENT_HASH>

Step 3: Trigger the Pipe

Fetch data from Directus and deliver it to the target endpoint. You can filter data using Directus query parameters.

stacker pipe trigger <PIPE_INSTANCE_ID> \
  --source-url "http://project-directus-1:8055/items/pages?filter[status][eq]=published" \
  --target-header "Authorization: Bearer <YOUR_TOKEN>" \
  --json \
  --deployment <DEPLOYMENT_HASH>

What Happens Under the Hood

Agent fetches source - HTTP GET to the Directus endpoint, receiving JSON data
Field mapping applied - JSONPath expressions transform the data (e.g., $.data[0].title extracts the first item's title)
Delivery to target - HTTP POST to the target endpoint with auth headers and mapped data

Step 4: Check the Result

The JSON output includes the full execution status:

{
  "command_id": "cmd_abc123...",
  "status": "completed",
  "result": {
    "success": true,
    "source_data": {
      "data": [
        {"id": 1, "title": "Hello World", "status": "published"}
      ]
    },
    "mapped_data": {
      "content": "Hello World"
    },
    "target_response": {
      "status": 200,
      "delivered": true,
      "transport": "http"
    }
  }
}

Real-World Examples

Sync Directus Content to Chatwoot

stacker pipe activate <PIPE_ID> \
  --source-url "http://project-directus-1:8055/items/knowledge_base" \
  --trigger manual \
  --target-header "Authorization: Bearer <CHATWOOT_TOKEN>" \
  --deployment <DEPLOYMENT_HASH>

stacker pipe trigger <PIPE_ID> \
  --source-url "http://project-directus-1:8055/items/knowledge_base?filter[category][eq]=faq" \
  --json \
  --deployment <DEPLOYMENT_HASH>

Send Directus Notifications to Slack

stacker pipe activate <PIPE_ID> \
  --source-url "http://project-directus-1:8055/items/notifications" \
  --trigger manual \
  --target-header "Authorization: Bearer <SLACK_BOT_TOKEN>" \
  --target-header "Content-Type: application/json" \
  --deployment <DEPLOYMENT_HASH>

stacker pipe trigger <PIPE_ID> \
  --source-url "http://project-directus-1:8055/items/notifications?filter[read][eq]=false" \
  --json \
  --deployment <DEPLOYMENT_HASH>

Push Directus Changes to an External API

stacker pipe activate <PIPE_ID> \
  --source-url "http://project-directus-1:8055/items/products" \
  --trigger manual \
  --target-header "X-API-Key: <YOUR_API_KEY>" \
  --deployment <DEPLOYMENT_HASH>

stacker pipe trigger <PIPE_ID> \
  --source-url "http://project-directus-1:8055/items/products?filter[updated_at][gt]=2026-01-01" \
  --json \
  --deployment <DEPLOYMENT_HASH>

Why `source_url` Changes Everything

Before source_url, pipes required source_container - the agent had to be on the same Docker network as the source service. This meant complex network configuration and no support for authenticated APIs.

With source_url:

Agent fetches any HTTP endpoint directly
Works across Docker networks
Supports target_headers for authentication
No curl needed - everything through stacker pipe

Troubleshooting

"Source fetch failed with status 403"

Directus requires authentication. Add the admin token to the source URL or configure Directus public role permissions for read access.

"Target request failed with status 404"

The target endpoint path is incorrect. Double-check the API path - for Chatwoot, ensure you include the account ID: /api/v1/accounts/<ACCOUNT_ID>/conversations.

"Pipe instance ID is not active on this agent"

Activate the pipe first with stacker pipe activate before triggering.

Architecture Overview

┌──────────────┐     ┌──────────────┐     ┌──────────────┐
│   Directus   │     │  Stacker     │     │   Target     │
│              │     │  Agent       │     │   Service    │
└──────┬───────┘     └──────┬───────┘     └──────┬───────┘
       │                    │                    │
       │  HTTP GET          │                    │
       │◄───────────────────│                    │
       │  (source_url)      │                    │
       │                    │  field_mapping     │
       │                    │  (JSONPath)        │
       │                    │                    │
       │                    │  HTTP POST         │
       │                    │  (target_headers)  │
       │                    │───────────────────►│

Frequently Asked Questions

Can I use Stacker PIPEs without Directus?

Yes. PIPEs work with any HTTP source - Directus is just one example. You can fetch data from any REST API, CMS, or webhook endpoint.

Do PIPEs require the agent to be on the same Docker network?

With source_url, no. The agent fetches any HTTP endpoint directly. The older source_container method required network proximity.

How do I schedule recurring pipe triggers?

Use --trigger poll with an interval when activating the pipe. The agent will check for new data at the specified cadence.

What authentication methods are supported?

Pass any header with --target-header. Bearer tokens, API keys, basic auth - any HTTP header works.

Key Takeaways

Stacker PIPEs replace custom curl scripts with three CLI commands
source_url enables cross-network, authenticated API integration
JSONPath field mapping transforms data without custom code
Works with Directus, Chatwoot, Slack, or any HTTP endpoint
Pipes are reusable - activate once, trigger as needed