gnt.ai Rules API
The rules API from gnt.ai — 9 operation(s) for rules.
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.
Call it yourself
curl for this page
This API
curl "https://apis.io/api/v1/apis/gntai-dev:gntai-dev-rules-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
openapi: 3.2.0
info:
title: AI GNT Rules API
version: 0.1.0
servers:
- url: https://api.gntai.dev
description: Production
tags:
- name: Rules
paths:
/v1/rules:
post:
tags:
- Rules
summary: Create Rule
operationId: create_rule_v1_rules_post
security:
- HTTPBearer: []
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateRuleRequest'
responses:
'201':
description: Successful Response
content:
application/json:
schema: {}
'422':
description: Validation Error
content:
application/json:
schema:
$ref: '#/components/schemas/HTTPValidationError'
get:
tags:
- Rules
summary: List Rules
operationId: list_rules_v1_rules_get
security:
- HTTPBearer: []
parameters:
- name: status
in: query
required: false
schema:
anyOf:
- type: string
- type: 'null'
title: Status
responses:
'200':
description: Successful Response
content:
application/json:
schema: {}
'422':
description: Validation Error
content:
application/json:
schema:
$ref: '#/components/schemas/HTTPValidationError'
/v1/rules/staleness/due:
get:
tags:
- Rules
summary: Get Rules Due For Revalidation
description: 'Approved rules this org''s last nightly compute_rule_staleness run
flagged as past the staleness threshold — due for a human to confirm
still true, or open a deprecation/refresh PR. Backs `gnt stale`.
A stopgap, not the final home for this: the eventual plan is to
surface this prompt in a weekly digest email, which doesn''t exist
yet — it''s waiting on that digest itself and on the nightly
contradiction-sweep worker (workers/tasks_contradictions.py), which
also needs to land first. This list is the same underlying signal,
surfaced as CLI visibility instead — wire it into the digest once
that email exists rather than building a second parallel version of
it.
Registered before /{rule_id} in this file, but doesn''t actually need
to be — "staleness"/"due" are two path segments, "{rule_id}" matches
exactly one, so there''s no route collision to order around.'
operationId: get_rules_due_for_revalidation_v1_rules_staleness_due_get
security:
- HTTPBearer: []
parameters:
- name: limit
in: query
required: false
schema:
type: integer
default: 50
title: Limit
responses:
'200':
description: Successful Response
content:
application/json:
schema: {}
'422':
description: Validation Error
content:
application/json:
schema:
$ref: '#/components/schemas/HTTPValidationError'
/v1/rules/{rule_id}:
get:
tags:
- Rules
summary: Get Rule
operationId: get_rule_v1_rules__rule_id__get
security:
- HTTPBearer: []
parameters:
- name: rule_id
in: path
required: true
schema:
type: string
title: Rule Id
responses:
'200':
description: Successful Response
content:
application/json:
schema: {}
'422':
description: Validation Error
content:
application/json:
schema:
$ref: '#/components/schemas/HTTPValidationError'
/v1/rules/{rule_id}/submit:
post:
tags:
- Rules
summary: Submit Rule
operationId: submit_rule_v1_rules__rule_id__submit_post
security:
- HTTPBearer: []
parameters:
- name: rule_id
in: path
required: true
schema:
type: string
title: Rule Id
responses:
'200':
description: Successful Response
content:
application/json:
schema: {}
'422':
description: Validation Error
content:
application/json:
schema:
$ref: '#/components/schemas/HTTPValidationError'
/v1/rules/{rule_id}/propose:
post:
tags:
- Rules
summary: Propose Rule
description: 'Renders the rule to markdown and opens a PR against the org''s
connected repo. This is `approve`''s replacement — approval now means a
human merging that PR on GitHub, not an in-terminal keypress (see
docs/migration/RECONCILE_V2.md). The actual approved-status transition,
including the HMAC-signed write and the previous-version supersede
dance approve_rule used to do here, happens in the webhook handler
once a real merge is confirmed — this endpoint only ever writes
`pending_merge`, never `approved`, so none of that machinery belongs
in this function anymore.'
operationId: propose_rule_v1_rules__rule_id__propose_post
security:
- HTTPBearer: []
parameters:
- name: rule_id
in: path
required: true
schema:
type: string
title: Rule Id
responses:
'200':
description: Successful Response
content:
application/json:
schema: {}
'422':
description: Validation Error
content:
application/json:
schema:
$ref: '#/components/schemas/HTTPValidationError'
/v1/rules/batch-propose:
post:
tags:
- Rules
summary: Batch Propose Rules
description: 'propose_rule''s batched sibling — one branch, one
put_file per rule, ONE pull request for the whole batch, and every
rule in it moves to pending_merge together carrying the SAME
prNumber/prUrl. Built for `gnt prebrain`''s draft-rule output (5-8
related rules reviewed as one PR), but not restricted to that caller.
Validation fails the WHOLE batch with a clear error naming the
offending rule(s) rather than silently skipping or partially
processing — a batch is one reviewable unit; a caller that asked for
5 rules and silently got 3 proposed has no way to know that happened
short of diffing IDs itself. Nothing GitHub-side happens until every
rule in the batch has already passed validation.'
operationId: batch_propose_rules_v1_rules_batch_propose_post
requestBody:
content:
application/json:
schema:
$ref: '#/components/schemas/BatchProposeRequest'
required: true
responses:
'200':
description: Successful Response
content:
application/json:
schema: {}
'422':
description: Validation Error
content:
application/json:
schema:
$ref: '#/components/schemas/HTTPValidationError'
security:
- HTTPBearer: []
/v1/rules/{rule_id}/reject:
post:
tags:
- Rules
summary: Reject Rule
operationId: reject_rule_v1_rules__rule_id__reject_post
security:
- HTTPBearer: []
parameters:
- name: rule_id
in: path
required: true
schema:
type: string
title: Rule Id
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/RejectRuleRequest'
responses:
'200':
description: Successful Response
content:
application/json:
schema: {}
'422':
description: Validation Error
content:
application/json:
schema:
$ref: '#/components/schemas/HTTPValidationError'
/v1/rules/{rule_id}/deprecate:
post:
tags:
- Rules
summary: Deprecate Rule
operationId: deprecate_rule_v1_rules__rule_id__deprecate_post
security:
- HTTPBearer: []
parameters:
- name: rule_id
in: path
required: true
schema:
type: string
title: Rule Id
responses:
'200':
description: Successful Response
content:
application/json:
schema: {}
'422':
description: Validation Error
content:
application/json:
schema:
$ref: '#/components/schemas/HTTPValidationError'
/v1/rules/{rule_id}/edit:
post:
tags:
- Rules
summary: Edit Rule
description: 'Creates a new draft version of an approved rule. The old rule stays
exactly as-is (still approved, still served) until the new version
is itself approved — see approve_rule''s supersede step.'
operationId: edit_rule_v1_rules__rule_id__edit_post
security:
- HTTPBearer: []
parameters:
- name: rule_id
in: path
required: true
schema:
type: string
title: Rule Id
requestBody:
required: true
content:
application/json:
schema:
$ref: '#/components/schemas/CreateRuleRequest'
responses:
'201':
description: Successful Response
content:
application/json:
schema: {}
'422':
description: Validation Error
content:
application/json:
schema:
$ref: '#/components/schemas/HTTPValidationError'
components:
schemas:
BatchProposeRequest:
properties:
rule_ids:
items:
type: string
type: array
minItems: 1
title: Rule Ids
type: object
required:
- rule_ids
title: BatchProposeRequest
description: 'Batches several already-in_review rules into ONE
PR instead of propose_rule''s one-PR-per-rule. A deliberate design
choice (not "fake" batching via pacing individual propose_rule calls): the
customer reviews 5-8 related rules as a single PR, not 5-8 separate
ones.'
RejectRuleRequest:
properties:
reason:
anyOf:
- type: string
- type: 'null'
title: Reason
type: object
title: RejectRuleRequest
CreateRuleRequest:
properties:
title:
type: string
maxLength: 200
minLength: 1
title: Title
body:
type: string
maxLength: 8000
minLength: 1
title: Body
confidence:
type: number
maximum: 1.0
minimum: 0.0
title: Confidence
default: 0.7
source_citations:
items:
additionalProperties: true
type: object
type: array
title: Source Citations
source:
anyOf:
- type: string
maxLength: 2000
- type: 'null'
title: Source
tags:
items:
type: string
type: array
maxItems: 20
title: Tags
type: object
required:
- title
- body
title: CreateRuleRequest
HTTPValidationError:
properties:
detail:
items:
$ref: '#/components/schemas/ValidationError'
type: array
title: Detail
type: object
title: HTTPValidationError
ValidationError:
properties:
loc:
items:
anyOf:
- type: string
- type: integer
type: array
title: Location
msg:
type: string
title: Message
type:
type: string
title: Error Type
input:
title: Input
ctx:
type: object
title: Context
type: object
required:
- loc
- msg
- type
title: ValidationError
securitySchemes:
HTTPBearer:
type: http
scheme: bearer