InfoLang Inc.

InfoLang Inc. Inquiries API

WHAT IS STILL BEING ASKED — `il-inquiry` pointed at the corpus. Every knowledge system files the answer and throws the question away, and is then structurally unable to say what is OUTSTANDING, who narrowed it into what, or that the question being answered today is not the one originally asked. For an intelligence operation that is the PIR/RFI loop verbatim. Refining a question does not answer it (IR2), splitting one supersedes it rather than answering it (IR3), an answer must NAME its evidence (IR4), and an agenda row is an equivalence CLASS rather than a question (IR6). Recall can annotate every subjected hit (`inquiries: true`) with the outstanding questions on its key, and filter to them (`only_outstanding`) — and a memory NEVER answers a question by arriving on its subject. All three lanes, gated on `coord:read` / `coord:write`; `501` where the upstream kernel verbs are not compiled in.

GitHub OpenAPI

Operations 9

POST /v2/workspaces/{id}/inquiries Open a question #
POST /v2/workspaces/{id}/inquiries/{inquiry}/narrow Refine a question — WITHOUT answering it #
POST /v2/workspaces/{id}/inquiries/{inquiry}/split Decompose a question into children #
POST /v2/workspaces/{id}/inquiries/{inquiry}/answer Answer a question by naming the assertion that answers it #
POST /v2/workspaces/{id}/inquiries/{inquiry}/abandon Give up on a question, with a reason #
POST /v2/workspaces/{id}/inquiries/{inquiry}/reopen Reverse one abandonment #
POST /v2/workspaces/{id}/inquiries/same-as Declare two questions to be one agenda row #
GET /v2/workspaces/{id}/agenda What is still outstanding #
GET /v2/workspaces/{id}/inquiries/{inquiry} One question's whole history #

Specifications

⚙
OpenAPI
https://artifacts.apis.io/infolang-ai/openapi/infolang-ai-inquiries-api-openapi.yml

Work with this as data

Every API here is available over the APIs.io API and to AI agents over MCP.

MCP server

One button, every client — Claude, Cursor, VS Code and the rest.

https://apis.io/mcp

Tools for apis

7 MCP tools reach this
  • find_apisBrowse and filter every API in the catalog.
  • get_api_artifactsOne API's artifacts, grouped by type.
  • get_openapiThe primary OpenAPI for this API.
  • find_similar_apisAPIs that look like this one.
  • apis_io_searchSTART HERE — APIs, providers and tags for one query, each with its total.
  • resolveTurn a domain, URL or GitHub org into the provider it belongs to.
  • find_cohortsEvery scored population of providers in the catalog.
All 92 tools →

Call it yourself

curl for this page
This API 
curl "https://apis.io/api/v1/apis/infolang-ai:infolang-ai-inquiries-api"
All apis 
curl "https://apis.io/api/v1/apis?limit=25"

Calls without X-API-Key need no key. Calls with it need a paid plan — get a key.

Get an API key

Free tier, no form to fill in. Signing in shares your email address with us — we store it to create your key and to recognise you if you sign in with another provider. See our Privacy Policy and Terms.

GitHub Google LinkedIn

A second provider on the same verified email joins the account you already have.

OpenAPI Specification

infolang-ai-inquiries-api-openapi.yml Raw ↑ 
openapi: 3.2.0
info:
  title: InfoLang Inquiries API
  version: 2.0.0
  description: 'The InfoLang gateway. `/v2` is the console + runtime API; the raw Kairos runtime surface stays proxied at `/v1` and `/mcp`, and **Canon** — the coordination layer — at `/coord/v1` where the deployment serves it (`capabilities.canon` on `GET /v2/me`). ## Three credential lanes


    Every `/v2` request carries a bearer token, and its prefix decides the lane:


    | Lane | Credential | For |

    |---|---|---|

    | **session** (`sessionAuth`) | Supabase session JWT | the website / console |

    | **oauth** (`oauthTokenAuth`) | `il_oauth_…` | a HUMAN who connected an MCP client (Claude, an IDE) |

    | **key** (`apiKeyAuth`) | `il_live_…` / `il_test_…` | MACHINES — SDKs, servers, CI |


    The gateway verifies only the session lane, minting a separate Kairos runtime token for upstream calls; the two `il_*` credentials are classified and forwarded verbatim, and Kairos verifies them and enforces the credential↔workspace binding. ## Which lanes a route accepts


    The general rule: **anything scoped to a workspace accepts all three lanes; the routes with no workspace in the path are session-only.** Concretely —


    - **All three lanes:** the runtime ops (`Runtime`), memories and namespaces (`Memories`), `GET /v2/whoami`, the read-only `Usage` and `Activity` views, and — since credential scoping — every `/v2/workspaces/{id}/…` route: keys, members, workspace CRUD, billing, ingest, webhooks, plus `GET /v2/me`. - **Session-only:** `POST /v2/bootstrap`, the workspace collection (`GET`/`POST /v2/workspaces`), the principal-keyed `/v2/billing` routes, and the console''s playground. These answer 403 `lane_not_supported` to an `il_*` credential: with no workspace in the path there is nothing for the gateway to bind the credential to. Each route''s `security` block is authoritative. **Accepting a lane is not granting access** — an `il_*` credential also has to carry the route''s scope (below). ## Scopes


    A credential may carry LESS authority than the principal behind it. Scopes are how you say so, and they are written `resource:action`:


    - `write` on a resource implies `read` on the same resource — `memories:write` covers recall. `workspace:delete` implies nothing else. - The resources are `memories`, `coord`, `compute`, `ingest`, `usage`, `activity`, `keys`, `members`, `workspace`, `billing` and `webhooks`. `compute:read` (encode, similarity) is stateless — it touches no stored data. `coord:read`/`coord:write` cover **Canon**, the coordination layer, and are enforced by Kairos on `/coord/v1/*` rather than by the gateway. - Wildcards (`*`, `:*`, `*:read`) are accepted **when creating** a credential and are resolved right then, into the concrete set. A wildcard will NOT silently widen to cover resources InfoLang adds later; to pick up a new resource, create a new credential. - A credential can be restricted to specific workspaces and given `not_before` and/or `expires_at`. Outside `[not_before, expires_at)` it is rejected with 401 `credential_expired`. - A credential can also be restricted to specific **namespaces** — the resource axis below workspace. See below; it has consequences worth reading before you grant one. - A credential minted before scoping shipped carries no scope record and resolves to a fixed legacy default, so nothing broke when scopes arrived. Each scoped route says below whether that default covers it. ### Two ceilings


    A request is allowed only if **both** hold:


    1. the credential''s scopes permit the operation, **and**

    2. the role of the principal behind the credential permits it on that workspace (Owner > Admin > Member > ReadOnly). **Neither ceiling can raise the other.** A key carrying `keys:write` held by a principal whose role is ReadOnly cannot manage keys; equally, an Owner presenting a key scoped only to `memories:read` cannot manage keys with it.'
servers:
- url: https://api.infolang.ai
  description: Production
tags:


# --- truncated at 32 KB (69 KB total) ---
# Full source: https://artifacts.apis.io/infolang-ai/openapi/infolang-ai-inquiries-api-openapi.yml