Custom event tracking via API and SDK for any application

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. No special configuration. No channel creation step. Send an event with your chosen source and type, and it appears in the timeline.

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 Shopify 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, Shopify, 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