Logo
NeoArc Studio

API Documentation

Document REST APIs with full endpoint specifications, OpenAPI import and export, seven HTTP methods, parameters, request and response bodies linked to shared schemas, authentication schemes, and a published API browser. REST is part of the API documentation suite (REST, GraphQL, gRPC, AsyncAPI, Webhooks, MCP) sharing a unified schema layer.

NeoArc Studio keeps API documentation with your other architecture content. Define endpoints once, reference them in design documents, embed them in architecture pages. Everything stays synchronised because it all lives in the same Git repository.

Endpoint Definitions

Document every aspect of your REST endpoints:

HTTP Methods
Support for GET, POST, PUT, PATCH, DELETE, OPTIONS, and HEAD. Each endpoint clearly shows its method and purpose.
Path and Query Parameters
Define parameters with names, types, descriptions, and whether they are required or optional. Document validation rules and default values.
Request Bodies
Specify request body schemas with support for content types. Link to schema definitions so request structures are always consistent.
Responses
Document all response codes your API can return. Include response schemas, example payloads, and explanations. Support for HTTP status codes.

Request and Response Bodies

Request and response definitions go beyond simple JSON examples. Each body specifies a default content type, a list of supported content types, and links to a shared schema definition.

AspectDetail
Content Typescontent types across categories: application (JSON, XML, form-urlencoded, octet-stream, PDF, msgpack, protobuf), text (plain, CSV, HTML, XML), multipart (form-data, mixed, related), and vendor-specific media types
Default Content TypeEach request body and response declares a default content type so consumers know the primary format without inspecting headers
Schema LinkingRequest and response bodies reference shared schema definitions. When the schema changes, all referencing endpoints reflect the update automatically
Multiple Response CodesEach endpoint documents responses per HTTP status code (200, 201, 400, 404, 409, 500, etc.) with separate schemas and descriptions for each
Example PayloadsAttach example JSON, XML, or other format payloads to request and response definitions for quick reference
Validation RulesSchema constraints (required fields, min/max values, patterns, enums) carry through from the schema definition into the API documentation

Authentication

Specify authentication requirements for each endpoint:

API Key
Header or query parameter options.
HTTP Authentication
Basic, Bearer, and Digest schemes.
OAuth 2.0
All grant types and scope definitions.
OpenID Connect
Identity-aware API authentication.
Mutual TLS
Certificate-based authentication.

Schema Integration

Schemas with ERD Lineage

These schemas trace fields back to database tables and columns:

Schemas with Graph Database Lineage

These healthcare schemas trace fields back to graph database nodes:

Embedding in Documents

Reference API endpoints directly in your architecture documentation. Use the REST API Endpoint content block to embed endpoint details inline:

In-Context Viewing
Readers see the endpoint specification in context without switching documents.
Auto-Updates
Embedded content updates when the source definition changes.

Library API (ERD Lineage)

Healthcare API (Graph Database Lineage)

These endpoints demonstrate APIs with lineage to graph database models:

Additional Features

Organisation
Group related endpoints into API definitions. Organise by domain, service, or however makes sense for your architecture.
Searchable
API definitions are included in the published site's search index. Find endpoints by paths, parameters, or descriptions.
Version Control
Track changes to your API documentation over time. See who changed what in pull request diffs. Roll back when needed.
OpenAPI Compatible
Export to OpenAPI 3.x format for use with other tools. Import existing OpenAPI specifications to get started quickly.

Evolution Tracking and Versioning

APIs change over time. NeoArc Studio tracks those changes with baseline-driven comparison, classifying each change as breaking, additive, deprecation, or cosmetic. The system recommends version bumps based on severity and supports a version-and-migrate workflow when major versions are needed.

Versioning Strategies
Choose semantic (1.2.3), major-minor (1.2), simple major (v2), date-based, or custom formats. Set the strategy once per API and the system follows it for version recommendations.
Change Classification
Compare against a baseline to see exactly what changed. Each change is classified by impact severity with automatic version bump recommendations.
Version-and-Migrate
When breaking changes require a new major version, the system creates a new versioned directory with copied API files and generates migration task suggestions.
Published Changelogs
Changelogs are included when you publish your site. Consumer teams browse version history and classified changes without needing repository access.