APIs

oper8r APIs let your team call search and cited answer tools from your own systems.

API access should follow the same permissions and review standards you use inside oper8r. Do not use API keys to bypass user permissions, move sensitive provider credentials into prompts, or generate unsupported claims.

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 tool.
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 '{
    "items": [
      {
        "query": "SSO, SCIM, audit logs, and data retention",
        "limit": 8
      }
    ]
  }'

Responses always return { "results": [...] }. One request still uses a one-item items array.

Public API Tools

Cited Answer Example

curl -X POST "https://YOUR_OPER8R_HOST/api/tools/org/YOUR_ORG_SLUG/oper8r_answer" \
  -H "Authorization: Bearer $OPER8R_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "items": [
      {
        "question": "How do we describe our SOC 2 controls?",
        "answer_context": "Use only approved security and compliance sources.",
        "requirements": ["concise", "cite approved evidence"],
        "limit": 8
      }
    ]
  }'

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.
• Avoid sending provider tokens, passwords, or unrelated personal data.