canonical: https://jentic.com/apis/biron-analytics.com/biron-analytics

# Biron Analytics Biron Nexus API

Jentic publishes the only available OpenAPI specification for Biron Nexus API, keeping it validated and agent-ready. Biron is a data platform that ships an ETL stack and a semantic layer on top of the customer's warehouse. The Nexus API is the programmatic surface to that semantic layer: clients submit NexusQL queries, which Biron compiles against the modelled metrics and dimensions, and the API returns tabular result sets. A second endpoint reads workspace metadata so callers know which datasets and metrics are available before composing a query.

## For AI agents

Run NexusQL queries against a Biron semantic layer and read workspace metadata to discover available metrics. Two endpoints, HTTP Basic authentication.

## Scope

Does not provision warehouses, run ETL jobs, or manage user permissions - use for executing NexusQL queries and reading workspace metadata only.

## Capabilities

- Execute a NexusQL query against the configured semantic layer via POST /sql and receive a tabular result set
- Read workspace metadata including available metrics and dimensions via GET `/workspaces/{code}`
- Pull modelled KPIs without writing SQL against raw warehouse tables
- Discover the canonical name of a metric before composing a downstream report
- Drive an embedded dashboard from agent-composed NexusQL queries

## Use cases

### Programmatic KPI retrieval for status reports

Operations teams pull weekly KPIs from the modelled semantic layer rather than querying raw warehouse tables. POST /sql accepts a NexusQL query and returns a tabular result that maps cleanly into a status-report template. Because the semantic layer enforces consistent metric definitions, two reports built by different teams converge on the same numbers.

Example prompt: POST /sql with a NexusQL query for weekly_active_users grouped by week for the last 12 weeks and render the result table

### Workspace discovery before query composition

Analysts who switch between several Biron workspaces need to confirm the available metrics before they write a NexusQL query. GET `/workspaces/{code}` returns the workspace definition including the list of metrics and dimensions Biron has modelled. The two-step pattern (discover then query) avoids failed /sql calls caused by referencing a metric that has not been published.

Example prompt: Call GET `/workspaces/revenue-ops`, list the metric names, and return them to the analyst as a picklist

### Agent integration via Jentic for self-serve analytics

An AI agent answering 'what was our revenue last quarter' resolves the question through Jentic. Jentic returns the Biron Nexus /sql operation along with the workspace schema, so the agent can compose a valid NexusQL query, execute it, and surface the result in chat. The HTTP Basic credentials remain in your Jentic One instance - the agent never holds them.

Example prompt: Search Jentic for 'run a nexusql query against biron', load the /sql schema, compose a query for revenue grouped by quarter, and return the result

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/sql` | Execute a NexusQL query against the configured workspace |
| GET | `/workspaces/{code}` | Return workspace metadata including modelled metrics and dimensions |

## Key resources

- **Queries** — Execute NexusQL queries against the modelled semantic layer via POST /sql
- **Workspaces** — Read workspace metadata including available metrics and dimensions via GET `/workspaces/{code}`

## Why Jentic

- **Setup:** Wiring the Biron Nexus API by hand means building the HTTP Basic Authorization header, targeting the nexus.biron-analytics.com host, and handling query errors yourself. Through Jentic you install once, import Biron Nexus from the API Directory, store the credentials once, and your agent calls it.
- **Permission scoping:** Biron Nexus sends the query in the request body for /sql, so limit the agent to the operations it needs, such as running a NexusQL query or reading workspace metadata with `/workspaces/{code}.` You choose the operations it may call, so nothing beyond that set runs unless you add it.
- **Credential handling:** Your Biron Basic credentials are stored once, encrypted, by your own Jentic One instance, which builds the Authorization header and injects it at execution time. They never enter the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'run a NexusQL query' or 'read a Biron workspace', and Jentic returns the matching operation with its input and response schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Snowflake API** — The cloud data warehouse that Biron's semantic layer commonly sits on top of.
- **The Graph** — Decentralised query layer for indexed data - different domain (on-chain) but same query-against-modelled-data shape.
- **RapidAPI** — Marketplace useful for surfacing alternative analytics and BI APIs.

## FAQ

### Why is there no official OpenAPI spec for Biron Nexus API?

Biron does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Biron Nexus API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Biron Nexus API use?

Biron Nexus uses HTTP Basic authentication. Clients send a username and password pair in the Authorization header on every request. Through Jentic the credential is held encrypted in the vault and injected at execution, so agents never see the password.

### Can I list the metrics in a Biron workspace before querying?

Yes. GET `/workspaces/{code}` returns the workspace definition including the list of modelled metrics and dimensions. Call it once to populate a picklist, then issue POST /sql with a NexusQL query that references those names.

### What are the rate limits for the Biron Nexus API?

Biron does not publish a numeric per-second rate limit in its specification. Treat /sql as a synchronous query against the underlying warehouse - long-running NexusQL queries occupy compute, so concurrency is bounded by the workspace's warehouse capacity rather than by an HTTP throttle.

### How do I run a NexusQL query through Jentic?

Run pip install jentic, search Jentic for 'run a nexusql query against biron', load the /sql operation schema, and execute with a NexusQL string in the body. Jentic injects the Basic credentials and returns the tabular result.

### Does the Biron Nexus API return raw warehouse data?

No. /sql executes NexusQL against the modelled semantic layer, not against raw warehouse tables. Use the workspace endpoint to discover the modelled metric and dimension names that NexusQL accepts.

### Can I limit what my agent is allowed to do with the Biron Nexus API?

Yes. Because you run Jentic One yourself, your own rules decide which Biron Nexus operations the agent may call, so you can allow only running a NexusQL query via POST /sql, only reading workspace metadata via GET `/workspaces/{code}`, or both. Anything outside the operation set you grant never runs unless you add it. Your HTTP Basic credentials stay in your own Jentic One instance and are injected at execution, so the agent scopes what it can reach without ever holding the password.