Skip to main content
Pylva needs cost-shaped telemetry and product configuration. It does not need private customer content. Send customer IDs, step names, provider/model, usage counts, latency, status, metrics, pricing, rules, alerts, invoice records, and portal settings. Do not send prompts, completions, raw messages, tool arguments, emails, API keys, provider credentials, authorization headers, request bodies, or private customer content.

​
Data Pylva needs

Pylva uses operational cost data:
  • customer_id and step_name.
  • Provider and model.
  • Token counts, latency, and status.
  • Metric and metric value for non-LLM usage.
  • Pricing configuration.
  • Rules, alerts, and webhook delivery settings.
  • Invoice records and customer portal settings.
Use opaque customer identifiers whenever possible.

​
Data Pylva does not need

Do not send:
  • Prompts or completions.
  • Raw messages or chat transcripts.
  • Raw tool arguments, tool inputs, or tool outputs.
  • Emails, phone numbers, or raw customer names when an opaque ID is available.
  • API keys, provider credentials, authorization headers, or request bodies.
  • Private customer content in metadata, step names, metric names, labels, or support messages.
See Privacy and PII for the short production checklist.

​
API keys

Pylva has one universal API key: it covers SDK telemetry, rules, pricing, budget sync, custom pricing, and data import. Because one key can operate the whole workspace, treat it like a password. Plaintext keys are shown once when created. Pylva stores one-way verification hashes for API keys, not the plaintext key. Put keys in a backend secret store and rotate or revoke them if exposed. Only workspace Owners can mint or revoke keys, every mint and revoke is audit-logged, and revocation propagates within seconds. Never expose any Pylva key in browser code, mobile apps, prompts, completions, logs, telemetry metadata, or support messages. See API keys for creation, prefixes, and rotation guidance.

​
Webhook security

Webhook delivery uses signed requests. Receivers should verify the raw request body with X-Pylva-Signature, X-Pylva-Timestamp, and the signing secret shown when the webhook is created or rotated. Save webhook signing secrets immediately and store them in your receiver’s secret store. See Alert Delivery And Webhooks for verification examples.

​
Support diagnostics

When sharing diagnostics, include:
  • Request IDs.
  • Batch IDs.
  • SDK version.
  • Timestamp.
  • Non-sensitive customer ID.
Do not include API keys, authorization headers, raw request bodies, prompts, completions, raw messages, raw tool arguments, provider credentials, or private customer content.

​
Cloud and self-hosting

Pylva Cloud manages the hosted infrastructure path: storage, upgrades, migrations, monitoring, retention, and scale for the managed service. Self-hosting gives your team direct control over deployment and operations. It also means your team operates PostgreSQL, ClickHouse, Redis, backups, monitoring, access controls, upgrades, migrations, and incident response. See Open Source And Hosted for the hosting model.

​
What not to assume

Do not assume formal compliance programs, enterprise identity features, contractual uptime commitments, private deployment options, dedicated support, or enterprise governance unless a Pylva page or agreement explicitly says they are available.