Metrx
Sign in
Trust

What Metrx stores

What reaches Metrx, what it keeps, who processes it for us, and how it is deleted. Each line describes what the code does today.

From your agents (SDK, OpenTelemetry, gateway)

  • Per model call: the model and provider, token counts (including cached tokens), cost, latency, success or error with an error code, the task ID, and the session ID, customer ID and trace IDs you choose to pass.
  • Per outcome: its type, when it happened, a value if you send one, the customer and reference IDs you pass, and any metadata you attach, stored exactly as sent.
  • When a task wrapped by an SDK throws, the SDK reports a failed outcome whose metadata carries the error message.

What Metrx does not receive

  • The SDKs and the OpenTelemetry exporter send no prompt or completion text, and Metrx reads no prompt or completion attributes from OpenTelemetry spans.
  • The Python SDK sends two hashes so repeated prompts can be grouped: a 16-character hash of the last prompt message and a hash of the reusable prefix (system prompt, tools, earlier messages). A hash is not the text, but a short or guessable prompt can be matched against its hash. The TypeScript SDK sends neither.
  • Through the optional Metrx gateway, prompts and completions pass through on their way to your model provider and are not stored; Metrx keeps the call’s metadata, a hash of the reusable prefix, and an upstream error message, cut to a fixed length.

From Zendesk

EVERY EVENT
  • Which trigger firedevent_type
  • The ticket IDid
  • The subject linesubject
  • The statusstatus
  • The prioritypriority
  • The assignee's nameassignee_name· about a person
  • The group namegroup_name
  • The requester's namerequester_name· about a person
  • The requester's email addressrequester_email· about a person
  • The tagstags
  • Your Zendesk subdomainsubdomain
  • When the ticket was last updatedoccurred_at
A SATISFACTION RATING ADDS
  • The rating (good or bad)satisfaction_score
  • The customer's rating commentsatisfaction_comment· about a person
  • The two triggers Metrx registers send these fields when a ticket is solved and when a customer rates it. Metrx stores each event as received.
  • The requester’s name and email, the assignee’s name and the customer’s rating comment are about people. The requester’s email is also stored as the outcome’s customer ID.
  • Metrx receives no internal notes and no ticket comment text.
  • Vendor bill check, when Metrx turns it on, also reads ticket event history through Zendesk’s incremental export. It requests no comment text and stores only the ticket ID, when the ticket was solved, closed or reopened, and whether a public reply was posted.
  • Disconnecting stops new events. It does not revoke the Zendesk token or remove the webhook and triggers; do that in Zendesk Admin Center.

Who processes data for Metrx

  • SupabaseThe database: everything listed on this page is stored here.
  • VercelHosts the web app and its API; Vercel Web Analytics counts page views.
  • CloudflareRuns the optional Metrx gateway and caches API-key checks for it.
  • ClerkSign-in and user accounts.
  • StripeBilling, and the Stripe outcome connection if you add it.
  • PostHogProduct analytics; a signed-in user is identified by email and name.
  • SentryError reports from the app and background workers.
  • UpstashRate limiting and short-lived queues (Redis).
  • InngestRuns scheduled and background jobs.
  • ResendSends account and alert email.
  • LoopsProduct-update email list: email address and first and last name.
  • Google FontsWeb fonts your browser loads from Google, which sees your IP address.
  • Connections you add (Zendesk, HubSpot, GitHub, Calendly, Stripe) and alert destinations you configure (Slack, Telegram) receive or send data on your instruction; each connection lists its fields before you approve it.
  • Model providers see your prompts because your agents call them; Metrx is not in that path unless you route calls through the optional gateway.

Where it lives, and agreements

  • Stored data lives in Supabase’s hosted PostgreSQL in the United States (AWS us-west-2, Oregon). The services above run in their own regions.
  • There is no public data processing agreement yet. To ask for one, write to legal@metrxbot.com.

Benchmarks

  • Your data is not used in cross-company benchmarks unless your organization opts in under Settings → BenchLytix data sharing, where it can also opt out and purge what it contributed.
  • An organization can also be excluded from benchmarks outright through the API.

Deletion

  • When the last member of an organization is removed, Metrx deactivates it automatically: stored connection credentials are destroyed, API keys and share links are revoked, Stripe Connect access is revoked, the subscription is set to cancel at the end of the paid period, and the user is unsubscribed from product-update email.
  • Deactivation keeps the organization’s data. Erasing it is a manual procedure an operator runs on request, which deletes the organization’s rows and records how many were deleted from each table.
  • Known gaps: the gateway can keep accepting a revoked API key for up to five minutes, and access you granted to Zendesk, HubSpot, GitHub or Calendly is not revoked at the provider; revoke it there.
  • Metrx does not yet delete old data on a schedule. To request erasure, write to legal@metrxbot.com.

Certification

  • Metrx holds no security certification today: no SOC 2 report and no ISO 27001 certificate.

How each number is computed: How Metrx counts