GraphJSON stores product, operational, and business events for analytical use. Security depends on both GraphJSON’s service controls and the customer’s decisions about what to send, who can access it, and how generated outputs are distributed.
This page is an engineering disclosure, not a certification or contractual security schedule.
Published architecture#
The current public architecture states:
- GraphJSON runs on Google Cloud Platform in the United States.
- Firebase provides account authentication and account metadata.
- Event data is stored in ClickHouse for analytical queries.
- Application, API, and embed traffic is served over HTTPS.
- Production infrastructure access is limited to GraphJSON maintainers and uses key-based authentication.
- Service backups support infrastructure recovery but are not customer-selectable snapshots.
- Stripe processes subscription payment information.
GraphJSON does not currently publish a customer-selectable data region.
Simplified data flow#
customer server or integration
│
│ HTTPS + workspace API key
▼
GraphJSON application and ingestion services
│
├─ account metadata and authentication
├─ event storage and analytical queries
├─ dashboards, alerts, and generated embeds
└─ billing and notification providers where used
The workspace key is sent in the JSON request body. It is not a public browser key and is not restricted to one collection.
Shared responsibility#
| Area | GraphJSON responsibility | Customer responsibility |
|---|---|---|
| Transport | Serve documented application and API surfaces over HTTPS | Use the HTTPS endpoint and do not downgrade transport |
| Authentication | Authenticate dashboard accounts and workspace API calls | Protect passwords, enable 2FA, and keep API keys server-side |
| Authorization | Scope workspace data and authenticated product surfaces | Authorize end users before generating tenant-specific embeds or data |
| Event contents | Store and query accepted JSON | Minimize data and exclude credentials, card data, and unnecessary PII |
| Retention | Provide collection retention controls | Choose an appropriate lifetime and preserve required archives |
| Backups | Maintain service recovery backups | Keep authoritative records and required customer-controlled archives |
| Embeds | Encrypt the query configuration in generated URLs | Treat generated URLs as bearer capabilities and scope them per audience |
| Integrations | Operate supported connection paths | Review source payloads, provider permissions, and event selection |
| Incident reporting | Receive availability and security reports | Send safe metadata promptly and rotate exposed customer credentials |
| Billing | Provide the subscription workflow and usage model | Maintain a billing owner and review invoices and stored-event growth |
Encryption#
GraphJSON publicly documents HTTPS for application, API, and embed traffic.
GraphJSON does not currently publish a detailed customer-facing specification for:
- encryption algorithms used for every category of data at rest
- customer-managed encryption keys
- key rotation schedules
- per-tenant cryptographic isolation
Do not claim those controls in a vendor review unless GraphJSON has provided a current written statement for the deployment.
Account and API access#
Dashboard access uses Firebase authentication. GraphJSON supports password authentication and SMS-based two-factor authentication.
The workspace API key can write events and request workspace data or embeds. It currently has no documented read-only, collection-scoped, or per-service variant.
Protect it by:
- storing it in a secret manager
- restricting deployment access
- keeping it out of URLs, browser bundles, mobile binaries, and logs
- inventorying every service that uses it
- contacting GraphJSON immediately when exposure is possible
Read Account security and recovery and API keys and security.
Event-data minimization#
Do not send:
- passwords or reset links
- session tokens, API keys, or authorization headers
- complete payment-card or bank information
- private keys or provider secrets
- raw private documents
- full request or response bodies without a reviewed allowlist
Prefer:
{
"event": "report_exported",
"event_id": "evt_01J...",
"account_id": "acct_7",
"report_type": "retention",
"row_count": 18420
}
over customer names, emails, report contents, headers, and complete application objects.
Customer-facing embeds#
A generated embed URL contains an encrypted configuration but functions as a bearer capability. Anyone who obtains it can load that configured result.
Your server must:
- authenticate the viewer
- derive the authorized account or user ID
- choose a fixed report definition
- add the tenant filter
- call GraphJSON with the API key
- return only the generated URL
Do not accept arbitrary SQL, collection names, or filters from a browser and append the workspace key.
Data lifecycle#
GraphJSON supports collection retention, collection deletion, clearing workspace events, and supported result exports.
Current limitations include:
- no documented self-service row-level deletion API
- no documented self-service whole-workspace raw archive endpoint
- no customer-selectable backup restore
- no guarantee that deleting source events removes screenshots, CSVs, cached copies, or downstream exports
Design privacy-request and archival workflows around those boundaries. See Export, delete, and move your data.
Service providers and subprocessors#
The public application and policies identify infrastructure, authentication, analytical storage, billing, email, and SMS services used to operate GraphJSON.
GraphJSON does not currently publish a complete contractual subprocessor register or automated change-notification subscription on this documentation site. Organizations that require a current subprocessor schedule, data-processing addendum, or advance notice of provider changes should contact hi@graphjson.com before sending regulated data.
Do not infer a complete subprocessor list from client-side source code or package dependencies. A dependency can be unused, self-hosted, or unable to access customer data.
Security incidents and vulnerability reports#
If an API key or customer payload may be exposed:
- stop the source of exposure
- restrict the repository, log, artifact, or shared URL
- preserve a narrow incident timeline
- identify affected workspaces and collections
- contact GraphJSON
- replace customer-controlled credentials
- reconcile unexpected writes or access
To report a suspected GraphJSON vulnerability, email hi@graphjson.com with a concise description, affected URL, and safe reproduction steps.
Do not include active secrets or unrelated customer data. GraphJSON does not currently publish a public bug-bounty program, security.txt commitment, or response-time SLA for vulnerability reports.
Compliance and assurance boundary#
GraphJSON does not currently claim a public:
- SOC 2 report
- ISO 27001 certification
- HIPAA business associate agreement
- PCI service-provider attestation
- external penetration-test report
- availability SLA
- recovery-time or recovery-point objective
Contact GraphJSON before a procurement or regulated workflow depends on any of these. Absence from this page should be treated as “not publicly committed,” not silently assumed.
Security review packet#
For a vendor review, record:
data categories:
identifiers:
expected volume:
retention:
required region:
required deletion workflow:
required export workflow:
required certifications:
required incident-notification period:
required RTO/RPO:
embed audience:
customer-side key storage:
workspace administrators:
Compare each requirement with the published boundary. Resolve gaps in writing before production launch.
Production checklist#
- API key is server-side and inventoried.
- Every team member has an individual account.
- SMS two-factor authentication is enabled.
- Event properties follow a reviewed allowlist.
- Retention is defined per collection.
- Required archives remain in a customer-controlled system.
- Personalized embeds derive filters from an authenticated session.
- Generated URLs are treated as bearer capabilities.
- Offboarding covers both membership and secrets.
- Security and incident contacts are current.
- Procurement requirements are matched to published controls.
For the public overview, see Security. For service availability boundaries, read Service status and incident communication.