Jentic Notes API

Free-form annotations attached to registry resources — an `Api`, an `ApiRevision`, a registered `operation_id`, an `ExecutionRecord`, or a `Credential`. Used to capture human or agent observations about quirks: *"this endpoint silently truncates email addresses to 64 chars"*, *"this credential rejects calls outside US business hours"*, *"this operation needs `Accept: application/json` even though the spec doesn't say so"*. Notes are an information surface for agents — they accumulate over time as the platform learns from real executions and surface back through `_links.notes` on the resources they annotate (woven in by individual surfaces as they need it). **Edit model.** Notes are editable via `PATCH`; each successful edit bumps a monotonic `revision` counter on the `Note`. Use the `If-Match` header on `PATCH` and `DELETE` to guard against concurrent modification. **Confidence promotion.** Notes carry both a `confidence` value (`observed | suspected | verified`) and a `confidence_source` (`client | platform_promoted`). Today only `client` is written by callers; the `platform_promoted` value is reserved for a future surface that auto-promotes `observed` notes to `verified` once enough matching `execution_feedback` accumulates. **Authentication.** Any authenticated principal (agent or human) can post any note type. Per-type policy (e.g. only humans may file `correction`) is enforced platform-side and not modelled in the spec.

Operations 5

GET /notes List Notes #
POST /notes Create Note #
DELETE /notes/{note_id} Delete Note #
GET /notes/{note_id} Get Note #
PATCH /notes/{note_id} Update Note #

Specifications

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/jentic:jentic-notes-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.

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

OpenAPI Specification

jentic-notes-api-openapi.yml Raw ↑
openapi: 3.2.0
info:
  contact:
    email: support@jentic.com
    name: Jentic Platform Team
    url: https://jentic.com/
  description: '## Overview ##

    The **Jentic Control Plane API** is the unified HTTP surface of the

    Jentic platform''s control plane — every administrative and

    metadata-facing endpoint outside the Broker data plane. The control plane is the administrative counterpart to the

    Broker data plane: where the Broker executes

    upstream API calls on behalf of agents, the control plane is where

    humans, operators, and agents configure *what* the Broker is

    allowed to do, *for whom*, *with which credentials*, *against

    which registered APIs*, and *with what telemetry retained*. ## Components ##

    High-level components for the control plane API. - **Core / Access** — credentials, toolkits,

    and PBAC grants and runtime params. Owns *who can call what, with which secret*. - **Registry** — registered APIs, immutable

    revisions, operations, search, lookup. Owns *what APIs are

    registered for this deployment and what they look like at any

    given revision*. - **Admin / Audit** — users, permissions,

    execution telemetry, async-job tracker, and dashboard event

    stream. Owns *who can sign in with what permissions* together

    with *what actually happened* — the human roster, the

    append-only records of brokered executions, the unified

    `Job` resource that both Registry imports and Broker

    async-execution calls feed into, and a curated `/events`

    surface for dashboards and operators. ## Authentication ##


    Today the platform ships a local username + password identity

    provider for human users, alongside agent identity (Dynamic Client

    Registration + RFC 7523 JWT-bearer assertions) and service-account

    client credentials — every authenticated operation expects

    `Authorization: Bearer ` (`BearerAuth`, an opaque `at_`

    token) except `GET /health`, `POST /auth/login`,

    `POST /users:create-admin`, and `POST /users:redeem-invite`. Human tokens are issued by `POST /auth/login` with a fixed 1-hour

    TTL and can be re-minted before expiry via `POST /auth/refresh`

    (sliding session, bounded by an absolute window —

    `admin.auth.session_ttl_seconds`, 12 hours by default); agents and

    service accounts obtain tokens from `POST /oauth/token` (see

    `BearerAuth`). The `permissions` claim on a token is a snapshot at

    issue time; permission changes take effect at the next re-issue —

    the next refresh or re-login (≤ 1 hour with the default TTL). The platform ships **no default credentials**. On a fresh

    install the users table is empty, so `GET /health` returns

    `setup_required: true` with `next_step: create_admin`. The

    operator creates the first administrator with `POST

    /users:create-admin {email, password}` — a one-time,

    unauthenticated, self-closing endpoint: it succeeds only while

    the users table is empty and returns `410 setup_already_complete`

    once any user exists (a single-row setup sentinel is the

    concurrency backstop, so two racing callers — even with different

    emails — cannot both bootstrap). It grants `org:admin`, sets the operator''s chosen

    password (so `must_change_password` is **false** — no forced

    rotation), and returns a ready-to-use `LoginResponse`

    (auto-login). After the first user exists `setup_required` flips

    to `false`. See the **Users** tag for the full onboarding

    walkthrough. External SSO providers (Okta, AWS Cognito, Auth0, Azure AD)

    plug in via the `User.auth_provider: external` hook plus an

    `external_subject_id` mapping; no concrete provider ships in

    this revision. Agent identity (separate from human users) uses

    Dynamic Client Registration (`POST /register`) with the agent''s

    JWKS, then RFC 7523 JWT-bearer assertions exchanged at

    `POST /oauth/token` for an opaque access token. ## Cross-cutting conventions


    - Every API reference uses the loose

    `APIReference(vendor, name, version)` data structure. There is no

    foreign key between Core, Registry, and Admin / Audit — the

    tuple is the only join. - **Error shape.** Every error response is RFC 9457 Problem

    Details (`application/problem+json`) using the shared

    `ProblemDetails` schema from

    jentic/api-problem-details.'
  license:
    identifier: Apache-2.0
    name: Apache-2.0
  summary: HTTP surface of the Jentic platform's control plane — Core / Access (credentials, toolkits), Registry (registered APIs, operations, search), and Admin / Audit (execution telemetry, async jobs).
  title: Jentic Control Plane Notes API
  version: 0.39.0
servers:
- description: Same-origin (relative)
  url: /
security:
- BearerAuth: []
tags:


# --- truncated at 32 KB (33 KB total) ---
# Full source: https://artifacts.apis.io/jentic/openapi/jentic-notes-api-openapi.yml