Integration

One command.
Live data in minutes.

Competitors make you write code to send events, then wait on a data team to model it. We come to where the data already is.

Three ways in. Pick the laziest one that works.

Every route ends in the same place: your usage, rated, on the same dashboards.

Agent

Usage that already exists in your infrastructure

Switch CDRs, gateway logs, call detail files. One install command, no code, no schema work. The agent tails what is already being written and forwards it.

Typical time to first event: ≈ 4 minutes

SDK

Usage that happens inside your application

A thin wrapper per ecosystem that handles auth, batching and retries. Seven lines and you are sending events. Node.js, PHP/Laravel and Python first; others by demand.

Typical time to first event: ≈ 10 minutes

Plain HTTPS API

Anything else at all

One endpoint, JSON in, per-item results out. No SDK required — this is the compatibility guarantee. If it can make an HTTPS request, it can integrate.

Typical time to first event: ≈ 15 minutes

The whole install.

This is not the short version of the install. This is the install. Run it on the box that already has your usage on it, paste your key when it asks, and watch the screen change.

  • Detects FreeSWITCH and Asterisk automatically
  • Buffers to disk if the network drops — nothing is lost
  • Runs as an unprivileged service, no inbound ports
  • Uninstall is one command too
Read the agent docs →
$curl -sL https://thepixeldata.com/install.sh | bash

Waiting for first event…

One event schema. That is the whole surface area.

A call, a message, a token batch, a shipment — all of them are this shape. Universality comes from one plain JSON contract, not from fifty bespoke integrations that each rot at a different speed.

properties is free-form and is what the rating engine matches on — a dialling prefix for telecom, a model name for AI, an APN for data. You do not have to decide up front; you can add a property later and write a plan line for it.

POST /v1/events
{
  "event_id": "5f0c1d84-6b1e-4a0e-9c7d-2e4b8f1a3c55",
  "event_type": "call",
  "timestamp": "2024-05-27T14:02:11Z",
  "account": "acct_alphacomms",
  "quantity": 372,
  "unit": "seconds",
  "properties": {
    "destination": "447700900123",
    "direction": "outbound",
    "trunk": "trunk-a"
  }
}

Seven lines, in your language.

import { PixelData } from "@pixeldata/node";

const pixel = new PixelData({ key: process.env.PIXEL_KEY });

await pixel.track({
  event_id: crypto.randomUUID(),
  event_type: "call",
  timestamp: new Date().toISOString(),
  account: "acct_alphacomms",
  quantity: 372,
  unit: "seconds",
  properties: { destination: "447700900123" }
});

The awkward cases, handled

Billing has no tolerance for “usually fine”. These are the three that catch everyone else out.

Send it twice, charged once

Every event carries an event_id you choose. Retry a batch, replay a queue, resend a whole day — duplicates inside seven days are dropped silently and nothing is billed twice.

Late events land in the right month

An event that arrives 72 hours after it happened is rated into the period it belongs to, against the plan version that was live at that instant — not the one that is live now.

One bad row never rejects the batch

Batch responses are per item. The valid events are accepted; the invalid ones come back naming the field and the fix. No all-or-nothing rejections.

Every API error names the field and the fix. Read the API reference or try it against thepixeldata.com in the sandbox.

Built for developers

Or none of the above — any language that can make an HTTPS request can integrate, with no SDK at all.

Fifteen minutes from now, this could be your data.

One command on the box that already has your usage on it. If you would rather look first, the sandbox is open.