No channel for it? Build your own.

Nine channels cover 90% of agency signals. The API covers everything else.

Burrow’s built-in channels — Code, Analytics, Ecommerce, Forms, Monitoring, Invoicing, Backups, System, and Automations — handle the signals most agencies need out of the box. Connect a CMS plugin or a platform integration and events start flowing.

But agencies build custom things. Client X has a Laravel API powering a membership portal. Client Y has a headless CMS with a custom publishing workflow. Client Z runs a proprietary checkout that doesn’t use Shopify or WooCommerce. Those systems generate operational signals too — and those signals belong in the same client timeline as everything else.

Custom channels let you send events from any system, using any naming convention, into the same Burrow project that holds the client’s WordPress events, GitHub deploys, and Stripe billing. And because every Burrow channel — first-class or custom — is rendered from the same event architecture, a custom channel isn’t a webhook bucket. It’s a full reporting product: its own dashboard, its own KPIs, its own event grammar.

From any feed to a full channel, without code

Some signals live in systems you can’t instrument — a donation platform, a booking engine, an industry-specific SaaS with nothing but a data feed. Pull connectors cover exactly that case. Paste the feed URL and Burrow parses it into editable query parameters; sensitive values are stored encrypted; the response can be XML or JSON. Run a test fetch, point at where the records live in the payload, and then event envelopes do the translation: rules evaluated top to bottom, each mapping the feed’s fields — IDs, dates, amounts in cents, tags — into properly typed Burrow events. Set the schedule, backfill up to a year of history, and every record ingests deduplicated from then on.

The real-world shape of this: a university client’s donation platform exposes an XML data feed. No plugin exists, and none is needed. A pull connector ingests every gift as donations.gift.successful with the campaign, form, amount, and page URL mapped into properties and tags — nightly, deduplicated, with a year of history backfilled on day one.

Dashboards you design

Events alone aren’t a report — so custom channels come with a widget builder. Compose KPIs (count or sum, filtered by any property or tag, formatted as numbers or currency, with period comparisons), daily timeseries charts, and breakdowns grouped by any property or tag — each widget showing a live preview against your real events while you configure it. Save, and the dashboard is shared with your whole org.

That donation feed becomes a Donations channel with gift counts, campaign and fund revenue KPIs, a daily contributions chart, a gift-form revenue breakdown, and a top-gifting-pages table — the kind of purpose-built reporting page a client would otherwise commission as a custom project. This is the point of the single event architecture: Burrow scales into any reporting tool a client needs, one channel at a time.

How it works

Every Burrow event follows the same envelope:

{
  "source": "membership-api",
  "type": "user.registered",
  "projectId": "client_acme",
  "payload": {
    "userId": "usr_4821",
    "plan": "premium",
    "referralSource": "landing-page-v2"
  }
}

The source identifies the system. The type identifies the event. The projectId scopes it to the client. The payload carries whatever metadata matters for your use case.

Send that payload via the REST API or the PHP/TypeScript SDKs, and it lands in Client Acme’s timeline alongside their WordPress form submissions, GitHub deploys, and WooCommerce orders. No channel configuration step. No schema registration. The event appears, categorized by its source, searchable by its type.

What agencies send through custom channels

Application health checks

source: "health-monitor"  |  type: "check.passed"  |  projectId: "client_acme"
source: "health-monitor"  |  type: "check.failed"  |  projectId: "client_acme"

Custom health checks that go beyond HTTP uptime — API response times, database connection health, third-party service availability, queue depth, memory usage. When the client’s API starts timing out, the event appears in the same timeline as the deploy that preceded it.

CI/CD pipeline events

source: "github-actions"  |  type: "pipeline.completed"  |  projectId: "client_acme"
source: "github-actions"  |  type: "pipeline.failed"  |  projectId: "client_acme"

For agencies using CI/CD beyond what GitHub’s native integration captures — custom test suites, staging deployments, database migration runs, build artifact generation. Each pipeline step becomes a visible event in the client timeline.

Custom CMS content events

source: "contentful"  |  type: "entry.published"  |  projectId: "client_acme"
source: "sanity"      |  type: "document.updated"  |  projectId: "client_acme"

Headless CMS platforms without native Burrow plugins — Contentful, Sanity, Strapi, Directus. Send content lifecycle events through the API so content publishes appear in the same timeline as deploys and form submissions.

Scheduled task outcomes

source: "scheduler"  |  type: "nightly_sync.completed"  |  projectId: "client_acme"
source: "scheduler"  |  type: "nightly_sync.failed"     |  projectId: "client_acme"

Cron jobs, scheduled data syncs, nightly report generation, database maintenance tasks. When the nightly sync that feeds the client’s dashboard fails silently, the event (or absence of it) is visible in Burrow. Scout monitors expected patterns and flags when scheduled events don’t fire on time.

Internal tool activity

source: "admin-panel"  |  type: "config.updated"   |  projectId: "client_acme"
source: "admin-panel"  |  type: "feature.toggled"   |  projectId: "client_acme"

Configuration changes, feature flag toggles, admin panel actions — anything that could affect the client’s production environment. When a feature toggle coincides with a conversion drop, the correlation is visible.

SDKs and API

PHP SDK — For WordPress plugins, Laravel applications, and any PHP backend:

$burrow->event([
    'source' => 'membership-api',
    'type'   => 'user.registered',
    'projectId' => 'client_acme',
    'payload' => ['plan' => 'premium'],
]);

TypeScript SDK — For Node.js applications, serverless functions, and Next.js API routes:

await burrow.event({
  source: 'membership-api',
  type: 'user.registered',
  projectId: 'client_acme',
  payload: { plan: 'premium' },
});

REST API — For any language or system that can make an HTTP POST. cURL, Python, Ruby, Go, Rust — if it speaks HTTP, it can send events to Burrow.

Custom events are first-class events

Custom events aren’t second-class citizens in Burrow. They participate in everything built-in events do:

• Timeline: Custom events appear chronologically alongside WordPress, WooCommerce, GitHub, and Stripe events
• Digests: Include custom event summaries in automated monthly reports
• Portals: Custom events are visible in read-only client portals
• Scout: Anomaly detection monitors custom event volume and patterns
• Correlation: A custom API health check failure next to a GitHub deploy tells the same story as a built-in monitoring alert

The event model is the same. The timeline is the same. The reporting is the same. The only difference is who sent the event — a built-in plugin or your code.

Agency operations | All channels | See all integrations