Influxdata
/
docs-v2
mirror of https://github.com/influxdata/docs-v2.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity

feat(api): unified API structure for Clustered and Cloud Dedicated 

- Update Authentication tag to cover both token types (management + database)
- Update Quick start to cover complete workflow (setup → write → query)
- Add dual download buttons on API landing pages
- Add context-aware download buttons on tag pages
- Remove old v2 HTML pages and duplicate auth directories
- Clean up management API specs (remove duplicate auth tags)

Part of API reference migration from Redoc to RapiDoc.
claude/api-code-samples-plan-MEkQO
Jason Stirnaman 2026-02-06 11:17:53 -06:00
parent 345bdc3058
commit f1b9ea5bc4
10 changed files with 641 additions and 580 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
api-docs/influxdb/cloud/v2/ref.yml
View File

@ -209,11 +209,31 @@ tags:
Retrieve data, analyze queries, and get query suggestions.
name: Query data
- description: |
See the [**API Quick Start**](/influxdb/cloud/api-guide/api_intro/)
to get up and running authenticating with tokens, writing to buckets, and querying data.
Authenticate, write, and query with the API:
[**InfluxDB API client libraries**](/influxdb/cloud/api-guide/client-libraries/)
are available for popular languages and ready to import into your application.
1. Create an API token to authorize API requests.
Use the InfluxDB Cloud UI or `POST /api/v2/authorizations`.
2. Write data to InfluxDB Cloud.
```bash
curl -X POST "https://cloud2.influxdata.com/api/v2/write?org=ORG_NAME&bucket=BUCKET_NAME&precision=ns" \
--header "Authorization: Token API_TOKEN" \
--data-raw "home,room=Kitchen temp=72.0
home,room=Living\ Room temp=71.5"
```
3. Query data using Flux.
```bash
curl -X POST "https://cloud2.influxdata.com/api/v2/query?org=ORG_NAME" \
--header "Authorization: Token API_TOKEN" \
--header "Content-Type: application/vnd.flux" \
--data 'from(bucket: "BUCKET_NAME") |> range(start: -1h)'
```
For more information, see the
[Get started](/influxdb/cloud/get-started/) guide.
name: Quick start
x-traitTag: true
- name: Resources

42
api-docs/influxdb/v2/v2/ref.yml
View File

@ -91,13 +91,11 @@ tags:
x-traitTag: true
- name: Compatibility endpoints
description: |
InfluxDB v2 provides a v1-compatible API for backward compatibility with InfluxDB 1.x clients and integrations.
InfluxDB v2 provides v1-compatible API endpoints for backward compatibility with InfluxDB 1.x clients and integrations.
Use these endpoints with InfluxDB 1.x client libraries and third-party integrations such as Grafana, Telegraf, and other tools designed for InfluxDB 1.x. The compatibility layer maps InfluxDB 1.x concepts (databases, retention policies) to InfluxDB v2 resources (buckets, organizations) through database retention policy (DBRP) mappings.
Use these endpoints with InfluxDB 1.x client libraries and third-party integrations such as Grafana, Telegraf, and other tools designed for InfluxDB 1.x.
- [Write data (v1-compatible)](#tag/Write-data-(v1-compatible))
- [Query data using InfluxQL (v1-compatible)](#tag/Query-data-(v1-compatible))
- [Manage v1-compatible users and permissions](#tag/Authorizations-(v1-compatible))
The compatibility layer maps InfluxDB 1.x concepts (databases, retention policies) to InfluxDB v2 resources (buckets, organizations) through database retention policy (DBRP) mappings.
- name: Config
- name: Dashboards
- description: |
@ -202,11 +200,37 @@ tags:
name: Query data
- name: Query data (v1-compatible)
- description: |
See the [**API Quick Start**](/influxdb/v2/api-guide/api_intro/)
to get up and running authenticating with tokens, writing to buckets, and querying data.
Authenticate, write, and query with the API:
[**InfluxDB API client libraries**](/influxdb/v2/api-guide/client-libraries/)
are available for popular languages and ready to import into your application.
1. Create an API token to authorize API requests.
Use the InfluxDB UI or `POST /api/v2/authorizations`.
2. Check the status of the InfluxDB server.
```bash
curl "http://localhost:8086/health"
```
3. Write data to InfluxDB.
```bash
curl -X POST "http://localhost:8086/api/v2/write?org=ORG_NAME&bucket=BUCKET_NAME&precision=ns" \
--header "Authorization: Token API_TOKEN" \
--data-raw "home,room=Kitchen temp=72.0
home,room=Living\ Room temp=71.5"
```
4. Query data using Flux.
```bash
curl -X POST "http://localhost:8086/api/v2/query?org=ORG_NAME" \
--header "Authorization: Token API_TOKEN" \
--header "Content-Type: application/vnd.flux" \
--data 'from(bucket: "BUCKET_NAME") |> range(start: -1h)'
```
For more information, see the
[Get started](/influxdb/v2/get-started/) guide.
name: Quick start
x-traitTag: true
- name: Ready

277
api-docs/influxdb3/cloud-dedicated/management/openapi.yml
View File

@ -28,21 +28,6 @@ security:
- bearerAuthManagementToken: []
bearerAuthJwt: []
tags:
- name: Admin authentication (management operations)
x-traitTag: true
description: |
Authenticate requests to the InfluxDB Management API.
With InfluxDB 3 Cloud Dedicated, the InfluxDB Management API endpoints require the following credentials:
- `ACCOUNT_ID`: The ID of the [account](/influxdb3/cloud-dedicated/get-started/setup/#request-an-influxdb-cloud-dedicated-cluster) that the cluster belongs to. To view account ID and cluster ID, [list cluster details](/influxdb3/cloud-dedicated/admin/clusters/list/#detailed-output-in-json).
- `CLUSTER_ID`: The ID of the [cluster](/influxdb3/cloud-dedicated/get-started/setup/#request-an-influxdb-cloud-dedicated-cluster) that you want to manage. To view account ID and cluster ID, [list cluster details](/influxdb3/cloud-dedicated/admin/clusters/list/#detailed-output-in-json).
- `Authorization MANAGEMENT_TOKEN`: the `Authorization` HTTP header with a [management token](/influxdb3/cloud-dedicated/admin/tokens/management/).
See how to [create a management token](/influxdb3/cloud-dedicated/admin/tokens/management/).
By default, management tokens in InfluxDB 3 are short-lived tokens issued by an OAuth2 identity provider that grant a specific user administrative access to your InfluxDB cluster. However, for automation purposes, you can manually create management tokens that authenticate directly with your InfluxDB cluster and do not require human interaction with your identity provider.
<!-- ReDoc-Inject: <security-definitions> -->
- name: Database tokens
description: Manage database read/write tokens for a cluster
- name: Databases
@ -50,251 +35,40 @@ tags:
- name: Quick start
x-traitTag: true
description: |
Get started quickly with example API requests.
Authenticate, write, and query with the API:
The following example script shows how to use `curl` to make database and token management requests:
1. Create a management token using `influxctl token create`.
```shell
#!/bin/bash
2. Create a database using the Management API.
# Usage:
# Note the leading space in the command below to keep secrets out of the shell history
#
# ```
# MANAGEMENT_TOKEN=<MANAGEMENT_TOKEN> ACCOUNT_ID=<ACCOUNT_ID> CLUSTER_ID=<CLUSTER_ID> ./scripts/test_http_api_v0_endpoints.sh
# ```
```bash
curl -X POST "https://console.influxdata.com/api/v0/accounts/ACCOUNT_ID/clusters/CLUSTER_ID/databases" \
--header "Authorization: Bearer MANAGEMENT_TOKEN" \
--header "Content-Type: application/json" \
--data '{"name": "sensors"}'
```
# Env var validation
if [ -z "${MANAGEMENT_TOKEN}" ]; then
echo "
[Error]: ❌
\$MANAGEMENT_TOKEN env var is required.
"
exit 1
fi
3. Create a database token for read/write access.
if [ -z "${ACCOUNT_ID}" ]; then
echo "
[Error]: ❌
\$ACCOUNT_ID env var is required.
"
exit 1
fi
```bash
curl -X POST "https://console.influxdata.com/api/v0/accounts/ACCOUNT_ID/clusters/CLUSTER_ID/tokens" \
--header "Authorization: Bearer MANAGEMENT_TOKEN" \
--header "Content-Type: application/json" \
--data '{"description": "my token", "permissions": [{"action": "write", "resource": "sensors"}]}'
```
if [ -z "${CLUSTER_ID}" ]; then
echo "
[Error]: ❌
\$CLUSTER_ID env var is required.
"
exit 1
fi
4. Write data to InfluxDB Cloud Dedicated.
HOST="https://console.influxdata.com"
```bash
curl -X POST "https://CLUSTER_HOST/api/v2/write?bucket=sensors&precision=ns" \
--header "Authorization: Token DATABASE_TOKEN" \
--data-raw "home,room=Kitchen temp=72.0"
```
# Database request functions
list_databases () {
local response=$( \
curl \
--location "$HOST/api/v0/accounts/$ACCOUNT_ID/clusters/$CLUSTER_ID/databases" \
--header "Accept: application/json" \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
)
echo "$response"
}
5. Query data using SQL or InfluxQL with a Flight client or the HTTP API.
create_database () {
local databaseName=$1
local response=$( \
curl \
--location "$HOST/api/v0/accounts/$ACCOUNT_ID/clusters/$CLUSTER_ID/databases" \
--header "Accept: application/json" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
--data '{
"name": "'$databaseName'",
"maxTables": 75,
"maxColumnsPerTable": 90,
"retentionPeriod": 600000000000,
"partitionTemplate": [
{
"type": "tag",
"value": "abc"
},
{
"type": "bucket",
"value": {
"tagName": "def",
"numberOfBuckets": 5
}
}
]
}' \
)
echo "$response"
}
update_database () {
local databaseName=$1
local response=$( \
curl \
--location "$HOST/api/v0/accounts/$ACCOUNT_ID/clusters/$CLUSTER_ID/databases/$databaseName" \
--request PATCH \
--header "Accept: application/json" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
--data '{
"maxTables": 150,
"maxColumnsPerTable": 180,
"retentionPeriod": 1200000000000
}' \
)
echo "$response"
}
delete_database () {
local databaseName=$1
local response=$( \
curl \
--location "$HOST/api/v0/accounts/$ACCOUNT_ID/clusters/$CLUSTER_ID/databases/$databaseName" \
--request DELETE \
--header "Accept: application/json" \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
)
echo "$response"
}
# Token request functions
list_tokens () {
local response=$( \
curl \
--location "$HOST/api/v0/accounts/$ACCOUNT_ID/clusters/$CLUSTER_ID/tokens" \
--header "Accept: application/json" \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
)
echo "$response"
}
create_token () {
local response=$( \
curl \
--location "$HOST/api/v0/accounts/$ACCOUNT_ID/clusters/$CLUSTER_ID/tokens" \
--header "Accept: application/json" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
--data '{
"description": "my test token",
"permissions": [
{
"action": "write",
"resource": "database_one"
},
{
"action": "read",
"resource": "database_two"
}
]
}' \
)
echo "$response"
}
get_token () {
local token_id=$1
local response=$( \
curl \
--location "$HOST/api/v0/accounts/$ACCOUNT_ID/clusters/$CLUSTER_ID/tokens/$tokenId" \
--header "Accept: application/json" \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
)
echo "$response"
}
update_token () {
local token_id=$1
local response=$( \
curl \
--location "$HOST/api/v0/accounts/$ACCOUNT_ID/clusters/$CLUSTER_ID/tokens/$tokenId" \
--request PATCH \
--header "Accept: application/json" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
--data '{
"description": "my updated test token",
"permissions": [
{
"action": "database_one",
"resource": "read"
}
]
}' \
)
echo "$response"
}
delete_token () {
local token_id=$1
local response=$( \
curl \
--location "$HOST/api/v0/accounts/$ACCOUNT_ID/clusters/$CLUSTER_ID/tokens/$tokenId" \
--request DELETE \
--header "Accept: application/json" \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
)
echo "$response"
}
# Test database endpoints
databaseName="test_database_$RANDOM"
printf "\n🏗️ Creating database... 🏗️\n\n"
response="$(create_database $databaseName)"
echo $response | jq
printf "\n🏗️ Creating database successful 🏗️\n\n"
printf "\n⬆️ Updating database... ⬆️\n\n"
response="$(update_database $databaseName)"
echo $response | jq
printf "\n⬆️ Updating database successful ⬆️\n\n"
printf "\n⬇️ Listing databases... ⬇️\n\n"
response="$(list_databases)"
echo $response | jq
printf "\n⬇️ Listing databases successful ⬇️\n\n"
printf "\n🗑️ Deleting database... 🗑️\n\n"
response="$(delete_database $databaseName)"
echo $response | jq
printf "\n🗑️ Deleting database successful 🗑️\n\n"
# Test token endpoints
printf "\n🏗️ Creating token... 🏗️\n\n"
response="$(create_token)"
echo $response | jq
tokenId=$(echo $response | jq '.id')
printf "\n🏗️ Creating token successful 🏗️\n\n"
printf "\n⬇️ Getting token... ⬇️\n\n"
response="$(get_token $tokenId)"
echo $response | jq
printf "\n⬇️ Getting token successful ⬇️\n\n"
printf "\n⬆️ Updating token... ⬆️\n\n"
response="$(update_token $tokenId)"
echo $response | jq
printf "\n⬆️ Updating token successful ⬆️\n\n"
printf "\n📋 Listing tokens... 📋\n\n"
response="$(list_tokens)"
echo $response | jq
printf "\n📋 Listing tokens successful 📋\n\n"
printf "\n🗑️ Deleting token... 🗑️\n\n"
response="$(delete_token $tokenId)"
echo $response | jq
printf "\n🗑️ Deleting token successful 🗑️\n\n"
```
For more information, see the
[Get started](/influxdb3/cloud-dedicated/get-started/) guide.
- name: Tables
description: Manage tables in a database
paths:
@ -2019,7 +1793,6 @@ components:
x-tagGroups:
- name: Using the Management API
tags:
- Authentication
- Quick start
- name: All endpoints
tags:

58
api-docs/influxdb3/cloud-serverless/v2/ref.yml
View File

@ -35,31 +35,30 @@ tags:
InfluxDB 3 Cloud Serverless provides the following HTTP API endpoints for writing data:
- **Recommended**: [`/api/v2/write` endpoint](#operation/PostWrite)
for new write workloads or for bringing existing InfluxDB v2 write workloads to InfluxDB Cloud Serverless.
- [`/write` endpoint](#operation/PostLegacyWrite) for bringing existing InfluxDB v1 write workloads to InfluxDB Cloud Serverless.
- `/api/v2/write` endpoint (recommended) for new write workloads or for
bringing existing InfluxDB v2 write workloads to InfluxDB Cloud Serverless.
- `/write` endpoint for bringing existing InfluxDB v1 write workloads to
InfluxDB Cloud Serverless.
Both endpoints accept the same line protocol format and process data in the same way.
Both endpoints accept line protocol format and process data the same way.
### Query data
InfluxDB 3 Cloud Serverless provides the following protocols for executing a query:
- **Recommended**: _Flight+gRPC_ request that contains an SQL or InfluxQL query. See how to [get started querying InfluxDB using Flight and SQL](/influxdb3/cloud-serverless/get-started/query/).
- HTTP API [`/query` request](/influxdb3/cloud-serverless/api/#operation/GetLegacyQuery) that contains an InfluxQL query.
Use this protocol when bringing existing InfluxDB v1 query workloads to InfluxDB Cloud Serverless.
- Flight+gRPC request (recommended) that contains an SQL or InfluxQL query.
- HTTP API `/query` request that contains an InfluxQL query.
Use this protocol for existing InfluxDB v1 query workloads.
### InfluxDB v2 compatibility
The HTTP API [`/api/v2/write` endpoint](#operation/PostWrite) works with the [`Token` authentication scheme](#section/Authentication/TokenAuthentication) and existing InfluxDB 2.x tools and code for [writing data](/influxdb3/cloud-serverless/write-data/).
See how to [use the InfluxDB v2 HTTP API with InfluxDB 3 Cloud Serverless](/influxdb3/cloud-serverless/guides/api-compatibility/v2/).
The `/api/v2/write` endpoint works with Token authentication and existing
InfluxDB 2.x tools and code.
### InfluxDB v1 compatibility
The HTTP API [`/write` endpoint](#operation/PostLegacyWrite) and [`/query` endpoint](#operation/GetLegacyQuery) work with InfluxDB 1.x username/password [authentication schemes](#section/Authentication/) and existing InfluxDB 1.x tools and code.
See how to [use the InfluxDB v1 HTTP API with InfluxDB 3 Cloud Serverless](/influxdb3/cloud-serverless/guides/api-compatibility/v1/).
The `/write` and `/query` endpoints work with InfluxDB 1.x username/password
authentication and existing InfluxDB 1.x tools and code.
name: API compatibility
x-traitTag: true
- description: |
@ -252,13 +251,36 @@ tags:
- [Execute queries](/influxdb3/cloud-serverless/query-data/execute-queries/)
name: Query data
- description: |
Get started quickly with tutorials and client libraries.
Authenticate, write, and query with the API:
See the [**Get started**](/influxdb3/cloud-serverless/get-started/) tutorial
to get up and running authenticating with tokens, writing to buckets, and querying data.
1. Create a database token to authorize API requests in the InfluxDB Cloud
Serverless UI.
[**InfluxDB API client libraries and Flight clients**](/influxdb3/cloud-serverless/reference/client-libraries/)
are available to integrate InfluxDB with your application.
2. Write data to InfluxDB Cloud Serverless.
```bash
curl -X POST "https://cloud2.influxdata.com/api/v2/write?bucket=DATABASE_NAME&precision=ns" \
--header "Authorization: Token DATABASE_TOKEN" \
--header "Content-Type: text/plain; charset=utf-8" \
--data-raw "home,room=Kitchen temp=72.0
home,room=Living\ room temp=71.5"
```
If all data is written, the response is `204 No Content`.
3. Query data from InfluxDB Cloud Serverless using SQL or InfluxQL.
For best performance, use a Flight client to query data.
The HTTP API `/query` endpoint supports InfluxQL queries.
```bash
curl -G "https://cloud2.influxdata.com/query" \
--header "Authorization: Token DATABASE_TOKEN" \
--data-urlencode "db=DATABASE_NAME" \
--data-urlencode "q=SELECT * FROM home WHERE time > now() - 1h"
```
For more information about using InfluxDB Cloud Serverless, see the
[Get started](/influxdb3/cloud-serverless/get-started/) guide.
name: Quick start
x-traitTag: true
- name: Resources

258
api-docs/influxdb3/clustered/management/openapi.yml
View File

@ -28,18 +28,6 @@ security:
- bearerAuthManagementToken: []
bearerAuthJwt: []
tags:
- name: Admin authentication (management operations)
x-traitTag: true
description: |
Authenticate requests to the InfluxDB Management API.
With InfluxDB 3 Clustered, InfluxDB Management API endpoints require the following credential:
- `Authorization MANAGEMENT_TOKEN`: the `Authorization` HTTP header with a [management token](/influxdb3/clustered/admin/tokens/management/).
See how to [create a management token](/influxdb3/clustered/admin/tokens/management/).
By default, management tokens in InfluxDB 3 are short-lived tokens issued by an OAuth2 identity provider that grant a specific user administrative access to your InfluxDB cluster. However, for automation purposes, you can manually create management tokens that authenticate directly with your InfluxDB cluster and do not require human interaction with your identity provider.
- name: Database tokens
description: Manage database read/write tokens for a cluster
- name: Databases
@ -47,235 +35,40 @@ tags:
- name: Quick start
x-traitTag: true
description: |
Get started quickly with example API requests.
Authenticate, write, and query with the API:
The following example script shows how to use `curl` to make database and token management requests:
1. Create a management token using `influxctl token create`.
```shell
#!/bin/bash
2. Create a database using the Management API.
# Usage:
# Note the leading space in the command below to keep secrets out of the shell history
#
# ```
# MANAGEMENT_TOKEN=<MANAGEMENT_TOKEN> ./scripts/test_http_api_v0_endpoints.sh
# ```
```bash
curl -X POST "https://CLUSTER_HOST/api/v0/databases" \
--header "Authorization: Bearer MANAGEMENT_TOKEN" \
--header "Content-Type: application/json" \
--data '{"name": "sensors"}'
```
# Env var validation
if [ -z "${MANAGEMENT_TOKEN}" ]; then
echo "
[Error]: ❌
\$MANAGEMENT_TOKEN env var is required.
"
exit 1
fi
3. Create a database token for read/write access.
HOST="https://cluster-host.com"
```bash
curl -X POST "https://CLUSTER_HOST/api/v0/tokens" \
--header "Authorization: Bearer MANAGEMENT_TOKEN" \
--header "Content-Type: application/json" \
--data '{"description": "my token", "permissions": [{"action": "write", "resource": "sensors"}]}'
```
# Database request functions
list_databases () {
local response=$( \
curl \
--location "$HOST/api/v0/databases" \
--header "Accept: application/json" \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
)
echo "$response"
}
4. Write data to InfluxDB Clustered.
create_database () {
local databaseName=$1
local response=$( \
curl \
--location "$HOST/api/v0/databases" \
--header "Accept: application/json" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
--data '{
"name": "'$databaseName'",
"maxTables": 75,
"maxColumnsPerTable": 90,
"retentionPeriod": 600000000000,
"partitionTemplate": [
{
"type": "tag",
"value": "abc"
},
{
"type": "bucket",
"value": {
"tagName": "def",
"numberOfBuckets": 5
}
}
]
}' \
)
echo "$response"
}
```bash
curl -X POST "https://CLUSTER_HOST/api/v2/write?bucket=sensors&precision=ns" \
--header "Authorization: Token DATABASE_TOKEN" \
--data-raw "home,room=Kitchen temp=72.0"
```
update_database () {
local databaseName=$1
local response=$( \
curl \
--location "$HOST/api/v0/databases/$databaseName" \
--request PATCH \
--header "Accept: application/json" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
--data '{
"maxTables": 150,
"maxColumnsPerTable": 180,
"retentionPeriod": 1200000000000
}' \
)
echo "$response"
}
5. Query data using SQL or InfluxQL with a Flight client or the HTTP API.
delete_database () {
local databaseName=$1
local response=$( \
curl \
--location "$HOST/api/v0/databases/$databaseName" \
--request DELETE \
--header "Accept: application/json" \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
)
echo "$response"
}
# Token request functions
list_tokens () {
local response=$( \
curl \
--location "$HOST/api/v0/tokens" \
--header "Accept: application/json" \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
)
echo "$response"
}
create_token () {
local response=$( \
curl \
--location "$HOST/api/v0/tokens" \
--header "Accept: application/json" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
--data '{
"description": "my test token",
"permissions": [
{
"action": "write",
"resource": "database_one"
},
{
"action": "read",
"resource": "database_two"
}
]
}' \
)
echo "$response"
}
get_token () {
local token_id=$1
local response=$( \
curl \
--location "$HOST/api/v0/tokens/$tokenId" \
--header "Accept: application/json" \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
)
echo "$response"
}
update_token () {
local token_id=$1
local response=$( \
curl \
--location "$HOST/api/v0/tokens/$tokenId" \
--request PATCH \
--header "Accept: application/json" \
--header 'Content-Type: application/json' \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
--data '{
"description": "my updated test token",
"permissions": [
{
"action": "database_one",
"resource": "read"
}
]
}' \
)
echo "$response"
}
delete_token () {
local token_id=$1
local response=$( \
curl \
--location "$HOST/api/v0/tokens/$tokenId" \
--request DELETE \
--header "Accept: application/json" \
--header "Authorization: Bearer $MANAGEMENT_TOKEN" \
)
echo "$response"
}
# Test database endpoints
databaseName="test_database_$RANDOM"
printf "\n🏗️ Creating database... 🏗️\n\n"
response="$(create_database $databaseName)"
echo $response | jq
printf "\n🏗️ Creating database successful 🏗️\n\n"
printf "\n⬆️ Updating database... ⬆️\n\n"
response="$(update_database $databaseName)"
echo $response | jq
printf "\n⬆️ Updating database successful ⬆️\n\n"
printf "\n⬇️ Listing databases... ⬇️\n\n"
response="$(list_databases)"
echo $response | jq
printf "\n⬇️ Listing databases successful ⬇️\n\n"
printf "\n🗑️ Deleting database... 🗑️\n\n"
response="$(delete_database $databaseName)"
echo $response | jq
printf "\n🗑️ Deleting database successful 🗑️\n\n"
# Test token endpoints
printf "\n🏗️ Creating token... 🏗️\n\n"
response="$(create_token)"
echo $response | jq
tokenId=$(echo $response | jq '.id')
printf "\n🏗️ Creating token successful 🏗️\n\n"
printf "\n⬇️ Getting token... ⬇️\n\n"
response="$(get_token $tokenId)"
echo $response | jq
printf "\n⬇️ Getting token successful ⬇️\n\n"
printf "\n⬆️ Updating token... ⬆️\n\n"
response="$(update_token $tokenId)"
echo $response | jq
printf "\n⬆️ Updating token successful ⬆️\n\n"
printf "\n📋 Listing tokens... 📋\n\n"
response="$(list_tokens)"
echo $response | jq
printf "\n📋 Listing tokens successful 📋\n\n"
printf "\n🗑️ Deleting token... 🗑️\n\n"
response="$(delete_token $tokenId)"
echo $response | jq
printf "\n🗑️ Deleting token successful 🗑️\n\n"
```
For more information, see the
[Get started](/influxdb3/clustered/get-started/) guide.
- name: Tables
description: Manage tables in a database
paths:
@ -1725,7 +1518,6 @@ components:
x-tagGroups:
- name: Using the Management API
tags:
- Authentication
- Quick start
- name: All endpoints
tags:

70
content/influxdb3/cloud-serverless/api/api-compatibility/_index.md
View File

@ -11,14 +11,12 @@ description: >-
writing data:
- **Recommended**: `/api/v2/write` endpoint
for new write workloads or for bringing existing InfluxDB v2 write workloads to InfluxDB Cloud Serverless.
- `/api/v2/write` endpoint (recommended) for new write workloads or for
bringing existing InfluxDB v2 write workloads to InfluxDB Cloud Serverless.
- `/write` endpoint for bringing existing InfluxDB v1 write workloads to
InfluxDB Cloud Serverless.
InfluxDB Cloud Serverless.
Both endpoints accept the same line protocol format and process data in the
same way.
Both endpoints accept line protocol format and process data the same way.
### Query data
@ -28,36 +26,25 @@ description: >-
query:
- **Recommended**: _Flight+gRPC_ request that contains an SQL or InfluxQL
query. See how to [get started querying InfluxDB using Flight and
SQL](/influxdb3/cloud-serverless/get-started/query/).
- Flight+gRPC request (recommended) that contains an SQL or InfluxQL query.
- HTTP API [`/query` request](/influxdb3/cloud-serverless/api/) that contains
an InfluxQL query.
Use this protocol when bringing existing InfluxDB v1 query workloads to InfluxDB Cloud Serverless.
- HTTP API `/query` request that contains an InfluxQL query.
Use this protocol for existing InfluxDB v1 query workloads.
### InfluxDB v2 compatibility
The HTTP API `/api/v2/write` endpoint works with the `Token` authentication
scheme and existing InfluxDB 2.x tools and code for [writing
data](/influxdb3/cloud-serverless/write-data/).
The `/api/v2/write` endpoint works with Token authentication and existing
See how to [use the InfluxDB v2 HTTP API with InfluxDB 3 Cloud
Serverless](/influxdb3/cloud-serverless/guides/api-compatibility/v2/).
InfluxDB 2.x tools and code.
### InfluxDB v1 compatibility
The HTTP API `/write` endpoint and `/query` endpoint work with InfluxDB 1.x
username/password authentication schemes and existing InfluxDB 1.x tools and
code.
The `/write` and `/query` endpoints work with InfluxDB 1.x username/password
See how to [use the InfluxDB v1 HTTP API with InfluxDB 3 Cloud
Serverless](/influxdb3/cloud-serverless/guides/api-compatibility/v1/).
authentication and existing InfluxDB 1.x tools and code.
type: api
layout: single
staticFilePath: >-
@ -77,14 +64,12 @@ tagDescription: >-
writing data:
- **Recommended**: `/api/v2/write` endpoint
for new write workloads or for bringing existing InfluxDB v2 write workloads to InfluxDB Cloud Serverless.
- `/api/v2/write` endpoint (recommended) for new write workloads or for
bringing existing InfluxDB v2 write workloads to InfluxDB Cloud Serverless.
- `/write` endpoint for bringing existing InfluxDB v1 write workloads to
InfluxDB Cloud Serverless.
InfluxDB Cloud Serverless.
Both endpoints accept the same line protocol format and process data in the
same way.
Both endpoints accept line protocol format and process data the same way.
### Query data
@ -94,36 +79,25 @@ tagDescription: >-
query:
- **Recommended**: _Flight+gRPC_ request that contains an SQL or InfluxQL
query. See how to [get started querying InfluxDB using Flight and
SQL](/influxdb3/cloud-serverless/get-started/query/).
- Flight+gRPC request (recommended) that contains an SQL or InfluxQL query.
- HTTP API [`/query` request](/influxdb3/cloud-serverless/api/) that contains
an InfluxQL query.
Use this protocol when bringing existing InfluxDB v1 query workloads to InfluxDB Cloud Serverless.
- HTTP API `/query` request that contains an InfluxQL query.
Use this protocol for existing InfluxDB v1 query workloads.
### InfluxDB v2 compatibility
The HTTP API `/api/v2/write` endpoint works with the `Token` authentication
scheme and existing InfluxDB 2.x tools and code for [writing
data](/influxdb3/cloud-serverless/write-data/).
The `/api/v2/write` endpoint works with Token authentication and existing
See how to [use the InfluxDB v2 HTTP API with InfluxDB 3 Cloud
Serverless](/influxdb3/cloud-serverless/guides/api-compatibility/v2/).
InfluxDB 2.x tools and code.
### InfluxDB v1 compatibility
The HTTP API `/write` endpoint and `/query` endpoint work with InfluxDB 1.x
username/password authentication schemes and existing InfluxDB 1.x tools and
code.
The `/write` and `/query` endpoints work with InfluxDB 1.x username/password
See how to [use the InfluxDB v1 HTTP API with InfluxDB 3 Cloud
Serverless](/influxdb3/cloud-serverless/guides/api-compatibility/v1/).
authentication and existing InfluxDB 1.x tools and code.
alt_links:
core: /influxdb3/core/api/
enterprise: /influxdb3/enterprise/api/

66
content/influxdb3/cloud-serverless/api/quick-start/_index.md
View File

@ -1,19 +1,36 @@
---
title: Quick start
description: >-
Get started quickly with tutorials and client libraries.
description: |-
Authenticate, write, and query with the API:
1. Create a database token to authorize API requests in the InfluxDB Cloud
Serverless UI.
See the [**Get started**](/influxdb3/cloud-serverless/get-started/) tutorial
2. Write data to InfluxDB Cloud Serverless.
to get up and running authenticating with tokens, writing to buckets, and
querying data.
```bash
curl -X POST "https://cloud2.influxdata.com/api/v2/write?bucket=DATABASE_NAME&precision=ns" \
--header "Authorization: Token DATABASE_TOKEN" \
--header "Content-Type: text/plain; charset=utf-8" \
--data-raw "home,room=Kitchen temp=72.0
home,room=Living\ room temp=71.5"
```
If all data is written, the response is `204 No Content`.
[**InfluxDB API client libraries and Flight
clients**](/influxdb3/cloud-serverless/reference/client-libraries/)
3. Query data from InfluxDB Cloud Serverless using SQL or InfluxQL.
For best performance, use a Flight client to query data.
The HTTP API `/query` endpoint supports InfluxQL queries.
are available to integrate InfluxDB with your application.
```bash
curl -G "https://cloud2.influxdata.com/query" \
--header "Authorization: Token DATABASE_TOKEN" \
--data-urlencode "db=DATABASE_NAME" \
--data-urlencode "q=SELECT * FROM home WHERE time > now() - 1h"
```
For more information about using InfluxDB Cloud Serverless, see the
[Get started](/influxdb3/cloud-serverless/get-started/) guide.
type: api
layout: single
staticFilePath: >-
@ -22,20 +39,37 @@ weight: 100
tag: Quick start
isConceptual: true
menuGroup: Concepts
tagDescription: >-
Get started quickly with tutorials and client libraries.
tagDescription: |-
Authenticate, write, and query with the API:
1. Create a database token to authorize API requests in the InfluxDB Cloud
Serverless UI.
See the [**Get started**](/influxdb3/cloud-serverless/get-started/) tutorial
2. Write data to InfluxDB Cloud Serverless.
to get up and running authenticating with tokens, writing to buckets, and
querying data.
```bash
curl -X POST "https://cloud2.influxdata.com/api/v2/write?bucket=DATABASE_NAME&precision=ns" \
--header "Authorization: Token DATABASE_TOKEN" \
--header "Content-Type: text/plain; charset=utf-8" \
--data-raw "home,room=Kitchen temp=72.0
home,room=Living\ room temp=71.5"
```
If all data is written, the response is `204 No Content`.
[**InfluxDB API client libraries and Flight
clients**](/influxdb3/cloud-serverless/reference/client-libraries/)
3. Query data from InfluxDB Cloud Serverless using SQL or InfluxQL.
For best performance, use a Flight client to query data.
The HTTP API `/query` endpoint supports InfluxQL queries.
are available to integrate InfluxDB with your application.
```bash
curl -G "https://cloud2.influxdata.com/query" \
--header "Authorization: Token DATABASE_TOKEN" \
--data-urlencode "db=DATABASE_NAME" \
--data-urlencode "q=SELECT * FROM home WHERE time > now() - 1h"
```
For more information about using InfluxDB Cloud Serverless, see the
[Get started](/influxdb3/cloud-serverless/get-started/) guide.
alt_links:
core: /influxdb3/core/api/
enterprise: /influxdb3/enterprise/api/

184
docs/plans/2026-01-07-api-reference-rapidoc-migration.md Normal file
View File

@ -0,0 +1,184 @@
# API Reference RapiDoc Migration Plan
> **For Claude:** REQUIRED SUB-SKILL: Use superpowers:executing-plans to implement this plan task-by-task.
**Goal:** Migrate all InfluxDB products from Redoc-based API reference to the new RapiDoc-based UI that's already working for influxdb3-core and influxdb3-enterprise.
**Architecture:** The new API reference uses RapiDoc Mini to render OpenAPI specs. The generation script (`api-docs/scripts/generate-openapi-articles.ts`) processes OpenAPI specs and creates Hugo content pages with frontmatter that references spec files. Hugo layouts (`layouts/api/` and `layouts/api-operation/`) render these pages using the RapiDoc component.
**Tech Stack:** TypeScript (generation scripts), Hugo templates, RapiDoc web component, OpenAPI 3.0 specs
***
## Overview
### Products to Migrate
| Product | Status | Spec Location | Target Content Path |
| ----------------------- | ------- | ----------------------------------------------------------- | ----------------------------------------- |
| influxdb3-core | ✅ Done | `api-docs/influxdb3/core/v3/ref.yml` | `content/influxdb3/core/api/` |
| influxdb3-enterprise | ✅ Done | `api-docs/influxdb3/enterprise/v3/ref.yml` | `content/influxdb3/enterprise/api/` |
| cloud-dedicated | Partial | `api-docs/influxdb3/cloud-dedicated/management/openapi.yml` | `content/influxdb3/cloud-dedicated/api/` |
| cloud-serverless | Partial | `api-docs/influxdb3/cloud-serverless/v2/ref.yml` | `content/influxdb3/cloud-serverless/api/` |
| clustered | Partial | `api-docs/influxdb3/clustered/management/openapi.yml` | `content/influxdb3/clustered/api/` |
| cloud-v2 | Partial | `api-docs/influxdb/cloud/v2/ref.yml` | `content/influxdb/cloud/api/` |
| oss-v2 | Partial | `api-docs/influxdb/v2/v2/ref.yml` | `content/influxdb/v2/api/` |
| oss-v1 | Partial | `api-docs/influxdb/v1/v1/ref.yml` | `content/influxdb/v1/api/` |
| enterprise\_influxdb-v1 | Partial | `api-docs/enterprise_influxdb/v1/v1/ref.yml` | `content/enterprise_influxdb/v1/api/` |
### Key Files
- **Generation script:** `api-docs/scripts/generate-openapi-articles.ts`
- **Core conversion:** `api-docs/scripts/openapi-paths-to-hugo-data/index.ts`
- **Hugo layouts:** `layouts/api/`, `layouts/api-operation/`
- **RapiDoc component:** `assets/js/components/rapidoc-mini.ts`
- **Styles:** `assets/styles/layouts/_api-layout.scss`
***
**API Tag Page Consolidation Complete**
The API documentation structure has been refactored from individual operation pages to consolidated tag pages:
1. **Before**: Each API operation had its own page (e.g., `/api/v3/configure/distinct_cache/`)
2. **After**: All operations for a tag are rendered inline on the tag page (e.g., `/api/cache-data/#post-/api/v3/configure/distinct_cache`)
**Key implementation details:**
- Server-side TOC generated from frontmatter `operations` array using Hugo templates
- `safeURL` filter prevents Hugo from URL-encoding anchor slashes
- JavaScript `api-toc.ts` detects pre-rendered TOC and preserves it
- RapiDoc's `scrollToPath()` method handles TOC click navigation to shadow DOM elements
- `goto-path` attribute initializes RapiDoc to scroll to operation from URL hash on page load
- `update-route="true"` enables RapiDoc to update URL hash as user navigates
See [API tag pages design](2026-01-21-api-tag-pages-design.md) for link anchor patterns and route information.
## Fix all InfluxDB products
These products already have generated content but may need spec adjustments and testing.
### Task 1.1: Verify API Generation
**Files:**
- Check: `content/influxdb3/cloud-dedicated/api/_index.md`
- Check: `api-docs/influxdb3/cloud-dedicated/management/openapi.yml`
- Verify: `static/openapi/influxdb3-cloud-dedicated/`
**Step 1: Check existing generated content**
```bash
ls -la content/influxdb3/cloud-dedicated/api/
cat content/influxdb3/cloud-dedicated/api/_index.md
```
Expected: Should see `_index.md` and subdirectories for each tag.
**Step 2: Verify OpenAPI spec exists and is valid**
```bash
head -50 api-docs/influxdb3/cloud-dedicated/management/openapi.yml
```
Expected: Valid OpenAPI 3.x spec with `openapi:`, `info:`, `paths:` sections.
**Step 3: Run generation**
```bash
yarn build:api-docs
```
Or for just this product:
```bash
node api-docs/scripts/dist/generate-openapi-articles.js cloud-dedicated
```
**Step 4: Start Hugo and verify pages render**
```bash
npx hugo server --port 1315
```
Visit the product URL--for example: <http://localhost:1315/influxdb3/cloud-dedicated/api/>
Expected: API reference pages render with RapiDoc component showing operations.
**Step 5: Check for console errors**
Open browser DevTools, verify no JavaScript errors related to RapiDoc.
**Step 6: Commit if working**
```bash
git add content/influxdb3/cloud-dedicated/api/
git add static/openapi/influxdb3-cloud-dedicated/
git add data/article-data/influxdb3/cloud-dedicated/
git commit -m "feat(api): generate cloud-dedicated API reference with RapiDoc"
```
### How to generate API reference articles
**Step 1: Rebuild TypeScript**
```bash
cd api-docs/scripts && yarn build
```
Or from root:
```bash
tsc --project api-docs/scripts/tsconfig.json
```
**Step 2: Test compilation succeeded**
```bash
node api-docs/scripts/dist/generate-openapi-articles.js --help
```
**Step 3: Commit the config change**
```bash
git add api-docs/scripts/generate-openapi-articles.ts
git commit -m "feat(api): enable cloud-v2 product config for RapiDoc migration"
```
***
## Verification Checklist
Before considering migration complete:
- [ ] All product API pages render without errors
- [ ] RapiDoc "Try It Out" works for each product
- [ ] Mobile responsive layout works correctly
- [ ] Navigation menus updated
- [ ] Old URLs redirect to new locations
- [ ] E2E tests pass
- [ ] No console errors in browser DevTools
- [ ] Links validation passes
***
## Rollback Plan
If issues are found:
1. Revert the product config changes in `generate-openapi-articles.ts`
2. Remove generated content directories
3. Restore original navigation files from git history
```bash
git checkout HEAD~N -- content/influxdb/cloud/reference/api/
git checkout HEAD~N -- api-docs/scripts/generate-openapi-articles.ts
```
***
## Notes
- The `useTagBasedGeneration` option creates pages organized by OpenAPI tags (used for influxdb3 products)
- The path-based generation creates pages organized by API paths (used for v2 products)
- The `skipParentMenu` option prevents duplicate menu entries when existing reference pages have menus

145
docs/plans/2026-01-21-api-tag-pages-design.md Normal file
View File

@ -0,0 +1,145 @@
# API Tag Pages Design
## Overview
Consolidate API documentation onto tag pages, where each tag page displays all operations for that tag using RapiDoc. This replaces the previous path-based page structure.
## Goals
1. Keep tag-based navigation in the left sidebar
2. Remove operations as children of tags in the left sidebar
3. Each tag page displays all RapiDoc renderings for operations in that tag
4. "On this page" TOC links to Overview and each operation
5. No frame/internal scrolling - page scrolls naturally as one document
6. Consistent styling with existing implementation
7. Clear visual separation between operations
## URL Structure
- **Tag page:** `/influxdb3/core/api/cache-data/`
- **Operation anchor:** `/influxdb3/core/api/cache-data/#post-/api/v3/configure/distinct_cache`
## RapiDoc Anchor Reference
| Feature | Format/Value |
| ------------------------------ | ---------------------------------------------------------------------------------- |
| Anchor format | `#{method}-{path}` (e.g., `#post-/api/v3/configure/distinct_cache`) |
| `goto-path` attribute | Navigate to operation on load: `goto-path="post-/api/v3/configure/distinct_cache"` |
| `scrollToPath(path)` method | Programmatic navigation |
| `update-route` (default: true) | Updates URL hash as user scrolls |
| `route-prefix` (default: #) | Hash prefix for routes |
| Built-in anchors | `#overview`, `#servers`, `#auth`, `#operations-top` |
## Page Layout
```
┌─────────────────────────────────────────────────────────────┐
│ Header / Top Nav │
├──────────┬─────────────────────────────────────┬────────────┤
│ │ │ │
│ Left │ Main Content │ On This │
│ Sidebar │ │ Page TOC │
│ (nav) │ ┌─────────────────────────────┐ │ │
│ │ │ <h1>Cache data</h1> │ │ Overview │
│ │ │ <p>Tag description...</p> │ │ POST ... │
│ │ └─────────────────────────────┘ │ DELETE .. │
│ │ │ POST ... │
│ │ ┌─────────────────────────────┐ │ DELETE .. │
│ │ │ RapiDoc (full height, │ │ │
│ │ │ no internal scroll) │ │ │
│ │ │ │ │ │
│ │ │ - POST distinct_cache │ │ │
│ │ │ - DELETE distinct_cache │ │ │
│ │ │ - POST last_cache │ │ │
│ │ │ - DELETE last_cache │ │ │
│ │ │ │ │ │
│ │ └─────────────────────────────┘ │ │
│ │ │ │
├──────────┴─────────────────────────────────────┴────────────┤
│ Footer │
└─────────────────────────────────────────────────────────────┘
```
## RapiDoc Configuration
- `render-style="read"` - Linear document flow (no internal scrolling)
- `spec-url` - Tag-specific spec (e.g., `/openapi/influxdb3-core/tags/tags/influxdb3-core-cache-data.yaml`)
- `update-route="true"` - URL updates as user navigates (default)
- No fixed height on container - expands to fit content
## "On This Page" TOC
Generated server-side from frontmatter `operations` array:
```yaml
operations:
- operationId: PostConfigureDistinctCache
method: POST
path: /api/v3/configure/distinct_cache
summary: Create distinct cache
- operationId: DeleteConfigureDistinctCache
method: DELETE
path: /api/v3/configure/distinct_cache
summary: Delete distinct cache
```
TOC output:
```
ON THIS PAGE
- Overview
- POST /api/v3/configure/distinct_cache
- DELETE /api/v3/configure/distinct_cache
- POST /api/v3/configure/last_cache
- DELETE /api/v3/configure/last_cache
```
Links use `#{method}-{path}` format matching RapiDoc anchors.
## Hash Navigation
1. On page load, JS reads `window.location.hash`
2. If hash present, set RapiDoc's `goto-path` attribute (without the `#`)
3. RapiDoc's default `update-route=true` updates URL as user scrolls
4. Native URL sharing works
## Files to Modify
### Layouts
- `layouts/api/list.html` - Embed RapiDoc instead of operation cards grid
- `layouts/partials/api/rapidoc-tag.html` - New partial for tag-level RapiDoc
### JavaScript
- `assets/js/components/rapidoc-mini.ts` - Add hash-based `goto-path` initialization
### Remove/Deprecate
- `layouts/api-path/path.html` - Path page layout
- `layouts/partials/api/rapidoc-path.html` - Path partial
- Generated path pages in `content/influxdb3/*/api/v*/`
### Keep
- Tag-specific spec files (`static/openapi/influxdb3-core/tags/tags/`)
- Generation script for tag pages and article data
- All endpoints page
### Generation Script
- Remove `generatePathPages()` function
- Keep tag page generation
- Ensure frontmatter `operations` array is complete for TOC
## Development Scope
Focus on `influxdb3/core` first, then migrate other products.
## Testing
- Verify tag pages load with all operations rendered
- Test hash navigation (direct URL, TOC clicks, browser back/forward)
- Verify no internal scrolling - page flows naturally
- Check visual separation between operations
- Test "On this page" TOC links

93
docs/plans/2026-02-04-v1-api-deduplication-design.md Normal file
View File

@ -0,0 +1,93 @@
# InfluxDB v1 API Consistency Design
**Date:** 2026-02-04
**Goal:** Make InfluxDB v1 API specs consistent with other products by using the same Redocly-based overlay approach.
## Current State
- `api-docs/influxdb/v1/v1/ref.yml` - Complete standalone spec (OSS)
- `api-docs/enterprise_influxdb/v1/v1/ref.yml` - Complete standalone spec (Enterprise)
- Not using Redocly decorators or content overlays
- Not integrated with `getswagger.sh`
## Target State
- Both v1 products use `.config.yml` and `content/` overlays like other products
- Integrated with `getswagger.sh` and Redocly decorator pipeline
- Remove unused tag-groups decorator (not used by RapiDoc)
## Design Decisions
1. **Keep both specs as complete, standalone files** - Accept duplication for simplicity
2. **Use overlays for info and servers only** - Paths stay in each `ref.yml`
3. **Remove tag-groups entirely** - Not used by RapiDoc UI
## Implementation
### 1. Directory Structure
```
api-docs/
influxdb/
v1/
.config.yml # Redocly config
v1/
content/
info.yml # OSS info overlay
servers.yml # OSS servers overlay
ref.yml # Complete OSS spec (exists)
enterprise_influxdb/
v1/
.config.yml # Redocly config
v1/
content/
info.yml # Enterprise info overlay
servers.yml # Enterprise servers overlay
ref.yml # Complete Enterprise spec (exists)
```
### 2. Redocly Decorator Changes
**Remove (unused with RapiDoc):**
- `openapi/plugins/decorators/tags/set-tag-groups.cjs`
- `tag-groups.yml` loading from `docs-content.cjs`
- `set-tag-groups` references in `docs-plugin.cjs`
- All `content/tag-groups.yml` files across products
**Keep:**
- `set-info.cjs` - merges info.yml overlay
- `set-servers.cjs` - merges servers.yml overlay
- `replace-shortcodes.cjs` - handles doc URL placeholders
### 3. getswagger.sh Changes
Add functions:
```bash
function updateOSSV1 {
postProcess influxdb/v1/v1/ref.yml 'influxdb/v1/.config.yml' 'v1@1'
}
function updateEnterpriseV1 {
postProcess enterprise_influxdb/v1/v1/ref.yml 'enterprise_influxdb/v1/.config.yml' 'v1@1'
}
```
## Tasks
1. [x] Create `influxdb/v1/.config.yml`
2. [x] Create `influxdb/v1/v1/content/info.yml`
3. [x] Create `influxdb/v1/v1/content/servers.yml`
4. [x] Create `enterprise_influxdb/v1/.config.yml`
5. [x] Create `enterprise_influxdb/v1/v1/content/info.yml`
6. [x] Create `enterprise_influxdb/v1/v1/content/servers.yml`
7. [x] Remove tag-groups decorator and all tag-groups.yml files
8. [x] Add `updateOSSV1()` and `updateEnterpriseV1()` to getswagger.sh
9. [x] Test: Run getswagger.sh for both v1 products
10. [x] Test: Verify API pages render correctly
## Completed: 2026-02-04
All tasks completed successfully. The v1 products now use the same Redocly overlay pattern as other products.