oper8r Docs

APIs

Customer-facing implementation guide

Back to overview

oper8r APIs let approved teams call organization-scoped workflows, search, graph exploration, integration health, and curated tool endpoints from their own systems.

API access is intended for customer-approved use cases. Do not use API keys to bypass user permissions, write unreviewed private data into shared graphs, or move sensitive provider credentials into agent context.

Access Model

API access is organization-scoped.

Before using an endpoint:

  1. Create or request an oper8r API key.
  2. Confirm the organization slug.
  3. Enable the specific API endpoint for the organization.
  4. Confirm the minimum role and data scope for the workflow.
  5. Test with a small, reviewable request.

Endpoint Pattern

Shared org API tools follow this shape:

POST https://YOUR_OPER8R_HOST/api/tools/org/YOUR_ORG_SLUG/TOOL_KEY

Example:

curl -X POST "https://YOUR_OPER8R_HOST/api/tools/org/YOUR_ORG_SLUG/oper8r_search" \
  -H "Authorization: Bearer $OPER8R_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "query": "latest renewal risk for Acme",
    "limit": 8
  }'

Common API Tools

ToolUse
oper8r_searchSearch approved oper8r knowledge for grounded context.
oper8r_graph_exploreExplore entities and relationships by query or entity anchor.
oper8r_get_account_contextReturn a cited account brief for meeting prep, renewal, expansion, or GTM context.
oper8r_find_precedentFind prior deals, objections, security answers, negotiations, or internal examples.
oper8r_diagnose_riskDiagnose forecast, churn, expansion, or account risk using connected evidence.
oper8r_answer_rfp_security_questionDraft cited RFP or security answers with confidence and review guidance.
oper8r_integrations_statusCheck visible integration health without exposing credentials or raw provider metadata.

Employee Graph Curation APIs

Employee graph curation APIs are explicitly scoped to the organization-internal shared employee graph.

They can be used to:

  • Upsert source-backed entities and facts.
  • Attach external IDs.
  • Find facts and reconciliation candidates.
  • Preview and apply approved reconciliations.
  • Invalidate stale facts.
  • Merge verified duplicate entities.

They should not be used for customer-facing public graphs, private user memory, passwords, API keys, tokens, or speculative facts.

Safe Request Pattern

Use small, auditable calls first.

curl -X POST "https://YOUR_OPER8R_HOST/api/tools/org/YOUR_ORG_SLUG/oper8r_employee_graph_find_facts" \
  -H "Authorization: Bearer $OPER8R_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "text": "Acme executive sponsor",
    "includeInvalidated": false,
    "limit": 10
  }'

Then preview mutating decisions before applying them when the endpoint supports preview.

curl -X POST "https://YOUR_OPER8R_HOST/api/tools/org/YOUR_ORG_SLUG/oper8r_employee_graph_preview_reconciliation" \
  -H "Authorization: Bearer $OPER8R_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "inputFact": {
      "source": { "id": "account:acme" },
      "relation": "renewal_owner",
      "target": { "id": "person:jane-smith" },
      "description": "Jane Smith owns the Acme renewal.",
      "evidenceText": "CRM opportunity owner field lists Jane Smith for the Acme renewal."
    },
    "decisions": [
      {
        "candidateId": "fact_existing_owner",
        "action": "supersede_candidate",
        "reason": "CRM owner changed after the prior fact was written."
      }
    ]
  }'

Implementation Notes

  • Store API keys in your secret manager.
  • Keep endpoint access narrow.
  • Log request IDs and business context in your own system.
  • Prefer source-backed requests with citations or external IDs.
  • Avoid sending raw provider tokens, passwords, or unrelated personal data.

Talk to oper8r

Bring us the workflow, integration, or deployment constraint. We can build it with you, run it for you, or advise your team.