GraphJSON authenticates public API calls with a workspace API key in the JSON request body.
Authenticate a request#
curl --request POST \
--url https://api.graphjson.com/api/visualize/data \
--header 'Content-Type: application/json' \
--data '{
"api_key": "your_api_key",
"collection": "product_events",
"IANA_time_zone": "UTC",
"graph_type": "Samples",
"start": "1 day ago",
"end": "now",
"filters": []
}'
The body field is named exactly api_key.
GraphJSON does not currently accept this key as:
Authorization: Bearer ...- a query-string parameter
- a cookie
Find the key#
Open a collection’s Logging tab. The generated server-side examples include the workspace key.
The same key is used across collections in the workspace.
Store the key#
Use a secret environment variable:
GRAPHJSON_API_KEY=...
const apiKey = process.env.GRAPHJSON_API_KEY;
Do not hardcode it in source:
// Do not do this.
const apiKey = "actual_workspace_key";
Understand its scope#
The key can write events and request workspace data or embeds. It is not limited to the collection named in one request.
Enforce application authorization before calling GraphJSON. A customer ID supplied by a browser is not an authorization decision.
Browser applications#
Use a server boundary:
browser
└─ authenticated request → your server
├─ validates tenant access
├─ adds GraphJSON API key
└─ calls GraphJSON
← authorized data or iframe URL
Cross-origin support allows HTTP clients to reach the service, but it does not make a secret safe in a browser.
Authentication failures#
An invalid key generally returns:
{
"error": "Invalid API KEY"
}
with HTTP 400.
Do not retry an invalid-key response. Check the deployment secret, surrounding whitespace, and whether the key was replaced.
Replace an exposed key#
Contact hi@graphjson.com to replace an exposed key. Update every ingestion job, server, build system, and provider integration that uses it.
Never send the existing key in the support request.