You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: api-playground/mdx/configuration.mdx
+1-1Lines changed: 1 addition & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -3,7 +3,7 @@ title: 'MDX setup'
3
3
description: 'Generate docs pages for your API endpoints using `MDX`'
4
4
---
5
5
6
-
You can manually define API endpoints in individual `MDX` files rather than using an OpenAPI specification. This method provides flexibility for custom content, but we recommend generating API documentation from an OpenAPI specification file for most projects because it is more maintainable and feature-rich. However, creating `MDX` pages for an API can be useful to document small APIsor for prototyping.
6
+
You can manually define API endpoints in individual `MDX` files rather than using an OpenAPI specification. This method provides flexibility for custom content, but we recommend generating API documentation from an OpenAPI specification file for most projects because it is more maintainable and feature-rich. However, creating `MDX` pages for an API can be useful to document small APIs, prototyping, or when you want more control over where API endpoints are in the navigation.
7
7
8
8
To generate pages for API endpoints using `MDX`, configure your API settings in `docs.json`, create individual `MDX` files for each endpoint, and use components like `<ParamFields />` to define parameters. From these definitions, Mintlify generates interactive API playgrounds, request examples, and response examples.
Copy file name to clipboardExpand all lines: api-playground/openapi-setup.mdx
+2-87Lines changed: 2 additions & 87 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -185,9 +185,7 @@ When `x-mint: href` is present, the navigation entry will link directly to the s
185
185
186
186
## Auto-populate API pages
187
187
188
-
Add an `openapi` field to any navigation element in your `docs.json` to automatically generate pages for OpenAPI endpoints. You can control where these pages appear in your navigation structure, as dedicated API sections or with other pages.
189
-
190
-
The `openapi` field accepts either a file path in your docs repo or a URL to a hosted OpenAPI document.
188
+
Add an `openapi` field to any navigation element in your `docs.json` to automatically generate pages for OpenAPI endpoints. The `openapi` field accepts either a file path in your docs repo or a URL to a hosted OpenAPI document.
191
189
192
190
Generated endpoint pages have these default metadata values:
193
191
@@ -252,92 +250,9 @@ You can use multiple OpenAPI specifications in different navigation sections:
252
250
The `directory` field is optional and specifies where generated API pages are stored in your docs repo. If not specified, defaults to the `api-reference` directory of your repo.
253
251
</Note>
254
252
255
-
### Selective endpoints
256
-
257
-
When you want more control over which endpoints appear where in your documentation, you can reference specific endpoints in your navigation. This approach allows you to mix API endpoints with other documentation pages.
258
-
259
-
#### Set a default OpenAPI spec
260
-
261
-
Configure a default OpenAPI specification at the navigation level. This enables automatic endpoint inclusion throughout your documentation:
262
-
263
-
```json {3, 13-14}
264
-
{
265
-
"navigation": {
266
-
"openapi": "/path/to/openapi.json",
267
-
"tabs": [
268
-
{
269
-
"tab": "Getting started",
270
-
"pages": ["quickstart", "installation"]
271
-
},
272
-
{
273
-
"tab": "API reference",
274
-
"pages": [
275
-
"api-overview",
276
-
"GET /users",
277
-
"POST /users",
278
-
"guides/authentication"
279
-
]
280
-
}
281
-
]
282
-
}
283
-
}
284
-
```
285
-
286
-
Any page entry matching the format `METHOD /path` will generate an API page for that endpoint using the default OpenAPI spec.
287
-
288
-
#### OpenAPI spec inheritance
289
-
290
-
OpenAPI specifications are inherited down the navigation hierarchy. Child navigation elements inherit their parent's OpenAPI specification unless they define their own:
291
-
292
-
```json {3, 10-11, 16, 18-19}
293
-
{
294
-
"navigation": {
295
-
"openapi": "/path/to/openapi-v1.json",
296
-
"tabs": [
297
-
{
298
-
"tab": "API v1 reference",
299
-
"pages": [
300
-
"overview",
301
-
"authentication",
302
-
"GET /users",
303
-
"POST /users"
304
-
]
305
-
},
306
-
{
307
-
"tab": "API v2 reference",
308
-
"openapi": "/path/to/openapi-v2.json",
309
-
"pages": [
310
-
"GET /users",
311
-
"POST /users"
312
-
]
313
-
}
314
-
]
315
-
}
316
-
}
317
-
```
318
-
319
-
#### Individual endpoints
320
-
321
-
Reference specific endpoints without setting a default OpenAPI specification by including the file path:
322
-
323
-
```json {6-7}
324
-
{
325
-
"navigation": {
326
-
"pages": [
327
-
"introduction",
328
-
"user-guides",
329
-
"/path/to/openapi-v1.json POST /users",
330
-
"/path/to/openapi-v2.json GET /orders"
331
-
]
332
-
}
333
-
}
334
-
```
335
-
336
-
This approach is useful when you need individual endpoints from different specs or only want to include select endpoints.
337
-
338
253
## Create `MDX` files for API pages
339
254
340
-
For control over individual endpoint pages, you can also create `MDX` pages for each operation. This lets you customize page metadata, add content, omit certain operations, or reorder pages in your navigation at the page level.
255
+
For control over individual endpoint pages, create `MDX` pages for each operation. This lets you customize page metadata, add content, omit certain operations, or reorder pages in your navigation at the page level.
341
256
342
257
See an [example MDX OpenAPI page from MindsDB](https://github.com/mindsdb/mindsdb/blob/main/docs/rest/databases/create-databases.mdx?plain=1) and how it appears in their [live documentation](https://docs.mindsdb.com/rest/databases/create-databases).
Copy file name to clipboardExpand all lines: api-playground/overview.mdx
-19Lines changed: 0 additions & 19 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -48,25 +48,6 @@ We recommend generating your API playground from an OpenAPI specification. See [
48
48
}
49
49
```
50
50
51
-
To generate pages for only specific endpoints, list the endpoints in the `pages` property of the navigation element.
52
-
53
-
This example generates pages for only the `GET /users` and `POST /users` endpoints. To genereate other endpoint pages, add additional endpoints to the `pages` array.
Copy file name to clipboardExpand all lines: api-playground/troubleshooting.mdx
-30Lines changed: 0 additions & 30 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -71,34 +71,4 @@ If your API pages aren't displaying correctly, check these common configuration
71
71
72
72
Alternatively, if your reverse proxy prevents you from accepting `POST` requests, you can configure Mintlify to send requests directly to your backend with the `api.playground.proxy` setting in the `docs.json`, as described in the [settings documentation](/settings#param-proxy). When using this configuration, you will need to configure CORS on your server since requests will come directly from users' browsers rather than through your proxy.
73
73
</Accordion>
74
-
<Accordion title="OpenAPI navigation entries are not generating pages">
75
-
If you are using an OpenAPI navigation configuration, but the pages aren't generating, check these common issues:
76
-
77
-
1. **Missing default OpenAPI spec**: Ensure you have an `openapi` field set at the navigation level:
78
-
```json
79
-
{
80
-
"navigation": {
81
-
"openapi": "/path/to/openapi.json",
82
-
"pages": ["GET /users", "POST /users"]
83
-
}
84
-
}
85
-
```
86
-
87
-
2. **OpenAPI spec inheritance**: If using nested navigation, ensure child groups inherit the correct OpenAPI spec or specify their own.
88
-
89
-
3. **Validation issues**: Use `mint openapi-check <path-to-openapi-file>` to verify your OpenAPI document is valid.
90
-
</Accordion>
91
-
<Accordion title="Some OpenAPI operations appear in navigation but others don't">
92
-
93
-
1. **Hidden operations**: Operations marked with `x-hidden: true` in your OpenAPI spec won't appear in auto-generated navigation.
94
-
2. **Invalid operations**: Operations with validation errors in the OpenAPI spec may be skipped. Check your OpenAPI document for syntax errors.
95
-
3. **Manual vs automatic inclusion**: If you reference any endpoints from an OpenAPI spec, only the explicitly referenced operations will appear in navigation. No other pages will be automatically added. This includes operations that are referenced in child navigation elements.
96
-
</Accordion>
97
-
<Accordion title="Mixed navigation (OpenAPI and MDX pages) not working correctly">
98
-
When combining OpenAPI operations with regular documentation pages in navigation:
99
-
100
-
1. **File conflicts**: You cannot have both an `MDX` file and a navigation entry for the same operation. For example, if you have `get-users.mdx`, do not also include `"GET /users"` in your navigation. If you need to have a file that shares a name with an operation, use the `x-mint` extension for the endpoint to have the href point to a different location.
101
-
2. **Path resolution**: Navigation entries that don't match OpenAPI operations will be treated as file paths. Ensure your `MDX` files exist at the expected locations.
102
-
3. **Case sensitivity**: OpenAPI operation matching is case-sensitive. Ensure HTTP methods are uppercase in navigation entries.
Copy file name to clipboardExpand all lines: navigation.mdx
-37Lines changed: 0 additions & 37 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -260,43 +260,6 @@ While not required, we also recommend that you set an icon for each dropdown ite
260
260
261
261
---
262
262
263
-
## OpenAPI
264
-
265
-
Integrate OpenAPI specifications directly into your navigation structure to automatically generate API documentation. Create dedicated API sections or place endpoint pages within other navigation components.
266
-
267
-
Set a default OpenAPI specification at any level of your navigation hierarchy. Child elements will inherit this specification unless they define their own specification.
268
-
269
-
```json
270
-
{
271
-
"navigation": {
272
-
"openapi": "/path/to/openapi-v1.json",
273
-
"tabs": [
274
-
{
275
-
"tab": "API v1 reference",
276
-
"pages": [
277
-
"overview",
278
-
"authentication",
279
-
"GET /users",
280
-
"POST /users"
281
-
]
282
-
},
283
-
{
284
-
"tab": "API v2 reference",
285
-
"openapi": "/path/to/openapi-v2.json",
286
-
"pages": [
287
-
"GET /users",
288
-
"POST /users"
289
-
]
290
-
}
291
-
]
292
-
}
293
-
}
294
-
```
295
-
296
-
For more information about referencing OpenAPI endpoints in your docs, see the [OpenAPI setup](/api-playground/openapi-setup).
297
-
298
-
---
299
-
300
263
## Versions
301
264
302
265
Partition your navigation into different versions.
0 commit comments