Skip to content

Integration Hub

Beyond Retrieval v2 exposes a standard REST API that any HTTP client can consume. Whether you are building a Python back-office script, a JavaScript front-end, an n8n workflow, or a Make.com scenario, the integration pattern is the same: authenticate, call JSON endpoints, and parse the response envelope.


Integration Architecture

graph LR
    subgraph Clients
        PY[Python / httpx]
        JS[JavaScript / fetch]
        CURL[curl / REST Client]
        N8N[n8n Workflow]
        MAKE[Make.com Scenario]
        OTHER[Any HTTP Client]
    end

    subgraph "Beyond Retrieval v2"
        API[FastAPI REST API]
        AUTH[Auth Middleware]
        RAG[RAG Pipeline]
        VEC[Vector Store]
        LLM[LLM Provider]
    end

    PY --> API
    JS --> API
    CURL --> API
    N8N --> API
    MAKE --> API
    OTHER --> API
    API --> AUTH
    AUTH --> RAG
    RAG --> VEC
    RAG --> LLM

Base URL

Environment Base URL
Local development http://localhost:8000/api
Docker Compose http://localhost:8000/api
Production https://your-domain.com/api

All endpoint paths in this documentation are relative to the base URL.


Authentication

Every request (except GET /api/health and GET /api/auth/config) requires a Bearer token in the Authorization header:

Authorization: Bearer <token>
Mode When Behavior
Bypass BYPASS_AUTH=true in .env All requests succeed as dev-user (admin). Any string works as a token.
Production BYPASS_AUTH=false with auth keys configured JWT verified against JWKS endpoint

Local Development

With BYPASS_AUTH=true, you can use any non-empty string as your token (e.g. "dev"). All admin-level endpoints are accessible.


Response Envelope

Every endpoint wraps its payload in a standard JSON envelope:

{
  "success": true,
  "data": { ... },
  "error": null
}
{
  "success": false,
  "data": null,
  "error": "Human-readable error message"
}

Always Check success

The HTTP status code indicates transport-level success, but always check response.json()["success"] for application-level results. Some endpoints return 200 OK with "success": false for expected failures.


Content Types

Direction Content-Type
JSON requests application/json
File uploads multipart/form-data
All responses application/json

Error Codes

Code Meaning
200 OK
201 Created
400 Bad Request (missing field, invalid value, missing API key)
401 Unauthorized (missing or invalid token)
403 Forbidden (non-admin user)
404 Not Found
409 Conflict (file processing, storage disabled)
410 Gone (expired invite)
429 Rate Limited (LLM provider)
500 Internal Server Error
502 Bad Gateway (storage or external service failure)

API Sections Quick Reference

Section Base Path Endpoints Guide
Authentication /api/auth 1 Auth config
Notebooks /api/notebooks 7 Notebook CRUD
Settings /api/notebooks/{id}/settings 3 Per-notebook config
Documents /api/notebooks/{id}/documents 13 Upload, ingest, manage
Chat /api/notebooks/{id} 11 Conversations and RAG
Retrieval /api/notebooks/{id}/retrieval 9 Search strategies
Enhancement /api/notebooks/{id}/enhance 11 AI chunk enhancement
Health /api/notebooks/{id}/health 2 Data quality checks
Models /api/models 3 LLM and embedding catalogs
Admin /api/settings 11 API keys, storage, DB type
Sharing /api/notebooks/{id}, /api/invite 7 Notebook sharing

Integration Guides

Guide Language / Tool Best For
Developer API All platforms Recommended — external RAG & chat via API keys (Python, JS, cURL, n8n, Make.com, Zapier, PHP, Dart)
Python Python 3.9+ with httpx Full admin API (notebooks, documents, ingestion)
JavaScript JavaScript / TypeScript with fetch Full admin API from browser or Node.js
curl curl / any REST client Quick testing, CI/CD scripts, shell automation

Start Here

If you just want to query documents or chat from an external app, use the Developer API guide. It uses simple API keys — no OAuth or JWT setup required.


Common Workflow

Regardless of language, the typical integration workflow follows these steps:

sequenceDiagram
    participant C as Client
    participant API as Beyond Retrieval API

    C->>API: POST /notebooks/ (create)
    API-->>C: notebook_id

    C->>API: POST /notebooks/{id}/documents/upload
    API-->>C: file metadata

    C->>API: POST /notebooks/{id}/documents/ingest
    API-->>C: job_id

    loop Poll until done
        C->>API: GET /notebooks/{id}/documents/{file_id}/stage
        API-->>C: status + progress
    end

    C->>API: POST /notebooks/{id}/conversations
    API-->>C: conversation_id

    C->>API: POST /notebooks/{id}/conversations/{conv_id}/messages
    API-->>C: AI response + citations

    C->>API: POST /notebooks/{id}/messages/{msg_id}/feedback
    API-->>C: feedback saved
  1. Create a notebook -- the organizational container for your knowledge base
  2. Upload files -- PDF, DOCX, TXT, CSV, XLSX, MD
  3. Start ingestion -- parses, chunks, and embeds your documents
  4. Poll for completion -- ingestion runs as a background task
  5. Create a conversation -- a chat session within the notebook
  6. Send messages -- the RAG pipeline retrieves context and generates answers
  7. Submit feedback -- thumbs up/down for quality tracking