> For the complete documentation index, see [llms.txt](https://docs.digitalapi.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.digitalapi.ai/marketplace/concepts/concept-foundations.md).
# Foundations
Helix Marketplace is a multi-gateway API marketplace and developer portal. It federates the API gateways you already run into one branded place where teams publish APIs as products and consumers discover, subscribe to, and consume them. Helix manages APIs across gateways, so it is the marketplace layer rather than another gateway.
### What the marketplace is
Four capabilities, brought together over the gateways you operate:
* **Federate:** one portal over Apigee, Kong, APISIX, AWS, Azure, and IBM.
* **Publish:** turn APIs into governed, documented products.
* **Monetize:** products, plans, quotas, and usage metering.
* **Self-serve:** consumers discover, subscribe, and test on their own.
### The value loop
Published APIs become products in a governed catalogue. Consumers discover and subscribe, their usage produces analytics, and those signals guide the next round of publishing. Each pass compounds.
### The shift, and why it matters
The shift is from gatekept to self-service. Organisations that exposed their systems as governed API products outgrew the ones that kept them locked away.
| Old way | With Helix |
| ------------------------------------ | ----------------------------------------------- |
| Request access through an admin team | Consumers self-serve discovery and keys |
| Wait on a gatekeeper to publish | Publishing runs through governance, not tickets |
| Hand-written docs that drift | Docs generated from the spec, always current |
### The management plane
Helix sits above your gateways as a management plane. It reads from them and never proxies live traffic, so it stays out of the latency path while keeping control of the catalogue. Live API calls flow straight from a consumer app to the gateway; Helix imports, governs, publishes, and meters around that path.
### The two sides
The same platform serves two audiences, joined by Products and Subscriptions.
What each side covers
* **Provider side (publish and operate):** connect sources, import and govern APIs, publish, package APIs into products with plans, manage subscriptions, and monitor and administer the portal.
* **Consumer side (discover and consume):** browse the catalogue, evaluate docs and specs, sign up, create an app and subscribe, collect credentials, then test and track usage.
### Time to first call
The north-star metric is time to first call: how fast a new consumer makes their first successful call. Maturity runs from manual access taking days, to same-day self-registration, to under ten minutes, to instant in-browser try-it. Helix targets the top of that ladder with a public catalogue, always-current docs, in-browser testing, and copy-paste samples.
### Roles and responsibilities
* **Portal Admin / API Provider:** owns the platform and the APIs; lands on the control-plane dashboard.
* **Org Admin:** runs a tenant or organization; works in the Administration area, scoped to their org.
* **API Consumer:** discovers and consumes APIs; works in the developer portal.
> **How-to:** for step-by-step configuration, see the How-to guides.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://docs.digitalapi.ai/marketplace/concepts/concept-foundations.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.