Developers · GraphQL

The knowledge graph is yours to query.

Your knowledge graph belongs to you. Pulse exposes it as a real GraphQL endpoint so your developers can ask the questions we haven’t pre-built UIs for, build internal dashboards, and integrate the graph into the tools your team already lives in.

EndpointPOST /v1/graphql

Bearer token from /app/admin/api-keys with the read scope. Read-only. Mutations live on the REST surface.

Example: high-regret pricing decisions in last quarter

curl -X POST https://api.pulse.app/v1/graphql \
  -H "Authorization: Bearer pk_live_xxxxxxxxxxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "{
      decisions(since: \"2026-01-01\", regretScoreMin: 50, limit: 25) {
        id
        title
        decidedAt
        regretScore
        executionGapDays
        decidedBy { name email }
        topic { name canonicalAnswer }
      }
    }"
  }'

Schema (read-only)

decisions filter: since, topicId, status, regretScoreMin, executionGapDaysMin, limit
decision(id) single by id
features filter: stage, team, ownerId, shipped, limit
topics + topic(id) with nested decisions and disagreements
customers filter: health, limit
people with nested decisionsMade and openCommitments
disagreements filter: topicId, resolved, limit

Limits

Per-key: 100 req/min + 10,000 req/day (shared with the REST surface)
Per-endpoint: 5,000 GraphQL queries/day per key (separate cap)
Query depth capped at 8 nested selections
Query length capped at 10,000 chars
Each list field caps `limit` at 100

Error codes

401 unauthorized
403 insufficient_scope
413 payload_too_large (request body over 64 KB)
422 parse_error / validation_failed / query_too_deep
429 graphql_quota_exceeded
Field-level errors come back inside the GraphQL response body alongside `data`, per spec

See the REST API overview for the writable surface, or /docs/push-api for ingest. Need mutations on the GraphQL surface? Tell us why.