Skip to content
RebelCore Docs

Integration overview

The RebelCore™ API lets your application run inference against your customer’s semantic specs without using the portal UI. It’s the same agent the portal uses — same data, same curation, same audit trail — wrapped in a small HTTP surface for server-to-server use.

What you can do with it

  • Send a natural-language prompt and one or more spec IDs.
  • Get back a curated answer governed by the project’s LLM exposure level.
  • See every call show up in your customer’s audit panel for review.

What you’ll need before integrating

  1. A trained semantic spec. Build your data in the portal first — import the files, create a project, train the spec. The API only operates on specs that already exist.
  2. An API user. Created by your Customer Super Admin in the portal. See API users for the provisioning flow. The Super Admin walks away with a username and password — give those to your integration.
  3. The API base URL for your deployment. Production is https://api.rebelcore.ai. Self-hosted deployments use whatever URL your operator configured.

How a request flows

your application
   │
   │ 1. POST /api/v1/authorize  (username + password)
   │         ↓
   │    24-hour bearer token
   │
   │ 2. POST /api/v1/infer       (prompt + spec_ids, Authorization: Bearer ...)
   │         ↓
   │    curated answer

Two endpoints, both POST, both JSON in / JSON out. The token from step 1 is reused on every step-2 call until it expires (24 hours), at which point you re-authorise.

Endpoints at a glance

EndpointMethodAuthPurpose
/api/v1/authorizePOSTusername + passwordGet a bearer token
/api/v1/inferPOSTAuthorization: Bearer <token>Run inference

Each endpoint has its own page with the full request/response schema, error codes, and a working example.

Multi-tenancy and data scoping

Every /infer call is scoped to the customer the API user belongs to. You cannot query specs from another customer — even if you know their spec ID, the call returns 403. There is no shared data, no cross-customer fallback, no admin override.

If your application serves multiple end-customers, each one needs their own API user.

Exposure level — what gets returned

The answer you get back depends on the LLM exposure level configured on the project the spec belongs to:

  • Full — exact values, records, aggregates allowed.
  • Limited — qualitative summaries; exact values masked.
  • Advisory — qualitative business guidance only; no numbers, no records.

The /infer response includes the active exposure as a hint so your application can render the answer appropriately.

Audit

Every API call lands in the same audit pipeline as portal interactions. Your Customer Super Admin can review who made which call, what was asked, and what was returned, all from the audit panel. Calls made via the API are tagged so they can be filtered separately from portal traffic.

Rate limiting and availability

Rate limiting is handled at the platform edge. There is no per-call quota on the endpoint itself — you’ll get standard HTTP 429 Too Many Requests if you exceed your tier’s allowance. Retry with exponential backoff.

The API is designed for server-to-server use. Don’t embed the username and password in browser-facing JavaScript — the credentials are equivalent to a database login. Treat them like a service-account secret.

Next