Informational Components (Cards, Callouts)

Relevant source files

The following files were used as context for generating this wiki page:

• docs.json
• README.md
• api-reference/openapi.json
• package.json
• tsconfig.json

This document outlines the architecture and configuration of informational components within the Mintlify Starter Kit. The project utilizes a configuration-driven approach to structure and render documentation content, including navigation, API references, and developer guides. While the repository is a starter kit that uses various Mintlify components like cards and callouts, the source files primarily contain the configuration data that populates these components, rather than their direct implementation.

The core of the documentation's structure is defined in docs.json, which controls navigation, branding, and layout. The API reference section is dynamically generated from an OpenAPI specification file, api-reference/openapi.json, which serves as a structured informational source for endpoints and data models. The README.md file itself acts as the initial informational component for developers, guiding them through setup and local development.

Site Structure and Navigation

The primary mechanism for organizing informational content is the docs.json file. It dictates the entire navigation hierarchy, branding, and theme of the documentation site.

Sources: docs.json

Theming and Branding

The overall look and feel are controlled by top-level properties in docs.json. This includes the site name, color scheme, and logos for light and dark modes.

Property	Description	Example Value
name	The display name of the documentation site.	"Mint Starter Kit"
theme	The base theme to use.	"mint"
colors	Defines the primary, light, and dark colors for the theme.	{ "primary": "#16A34A", ... }
logo	Specifies paths to the logo for light and dark themes.	{ "light": "/logo/light.svg", ... }
favicon	Path to the site's favicon.	"/favicon.svg"

Sources: docs.json:3-12, docs.json:62-65

Navigation Hierarchy

The site's navigation is defined under the navigation key, which is organized into tabs, groups, and pages. This creates a multi-level structure for users to browse content.

The following diagram illustrates the navigation structure defined in docs.json.

The configuration also supports global navigation anchors and links in the navbar and footer, providing persistent informational links across the site.

Sources: docs.json:51-61, docs.json:66-75, docs.json:86-91

API Documentation Components

A significant informational component of this starter kit is the API reference, which is generated from the api-reference/openapi.json file. This file provides a structured, machine-readable definition of the "OpenAPI Plant Store" API.

Sources: api-reference/openapi.json

API Endpoints

The paths object in the OpenAPI spec defines the available endpoints. The documentation site renders these definitions into interactive informational components.

Path	Method	Description
/plants	GET	Returns all plants from the system that the user has access to.
/plants	POST	Creates a new plant in the store.
/plants/{id}	DELETE	Deletes a single plant based on the ID supplied.
/plant/webhook	POST	Webhook for information about a new plant added to the store.

Sources: api-reference/openapi.json:20-111, api-reference/openapi.json:112-129

The following sequence diagram shows the interaction for fetching a list of plants.

Data Schemas

The API's data models are defined under components.schemas. These schemas are used to generate documentation for request bodies and response payloads, serving as a critical informational resource for developers.

The diagram below shows the relationships between the Plant, NewPlant, and Error schemas. NewPlant extends Plant and adds an id.

Here is the JSON definition for the base Plant schema:

"Plant": {
  "required": [
    "name"
  ],
  "type": "object",
  "properties": {
    "name": {
      "description": "The name of the plant",
      "type": "string"
    },
    "tag": {
      "description": "Tag to specify the type",
      "type": "string"
    }
  }
}

Sources: api-reference/openapi.json:132-149

Developer-Facing Information

The repository contains several files that serve as informational components specifically for developers working on the project.

Development Workflow

The README.md file is the primary entry point for developers. It outlines the steps required to set up a local development environment to preview documentation changes.

Sources: README.md

The local development process can be visualized as follows:

Project Configuration

Files like package.json and tsconfig.json provide structural information about the project itself. While not end-user documentation, they are essential informational artifacts for developers, defining dependencies, scripts, and compiler settings.

• package.json: Defines project metadata, dependencies, and scripts. Its presence indicates a Node.js project structure.
• tsconfig.json: Configures the TypeScript compiler options, defining how .ts files are transpiled. Its presence indicates the project uses TypeScript.

Sources: package.json, tsconfig.json

Content Interactivity

The docs.json file also configures contextual tools that enhance informational content by making it interactive. The contextual.options array lists services that can be used to interact with code blocks, such as copying the code or opening it in various AI tools and editors.

"contextual": {
  "options": [
   "copy",
   "view",
   "chatgpt",
   "claude",
   "perplexity",
   "mcp",
   "cursor",
   "vscode"
 ]
}

Sources: docs.json:76-85

Summary

In the Mintlify Starter Kit, "Informational Components" are primarily managed through high-level configuration files rather than direct, in-code implementation. docs.json orchestrates the site's structure, navigation, and branding. api-reference/openapi.json provides a detailed, structured source for generating the API reference section. Finally, developer-focused files like README.md, package.json, and tsconfig.json provide the necessary information to set up, understand, and contribute to the project. This configuration-as-information approach allows for powerful, structured documentation that is easy to maintain and update.