Skip to main content

Cloud API

This page describes the Cloud API discovery entrypoints that the website currently publishes for automated clients and integrations.

The rule is simple: publish only capabilities that already exist and are documented. The site does not advertise private admin endpoints, unstable surfaces, or nonexistent OAuth or MCP discovery metadata.

Discovery entrypoints​

  • API catalog: https://qiugeapp.zhangqiu.pro/.well-known/api-catalog
  • OpenAPI: https://qiugeapp.zhangqiu.pro/.well-known/qiuge-cloud-api.openapi.json
  • Health endpoint: https://qiugeapi.zhangqiu.pro/api/cloud/health

Current authentication model​

The Cloud API currently uses platform-account login and bearer tokens for authenticated requests.

That means:

  • bearer-token authentication is documented
  • /.well-known/openid-configuration is not published
  • /.well-known/oauth-authorization-server is not published
  • /.well-known/oauth-protected-resource is not published

The reason is direct: the production service is not a standards-based OAuth or OIDC authorization server yet.

Documented public subset​

Public​

  • GET /api/cloud/health
  • POST /api/cloud/auth/register-code/request
  • POST /api/cloud/auth/register
  • POST /api/cloud/auth/login

Authenticated​

  • POST /api/cloud/auth/refresh
  • GET /api/cloud/me
  • PATCH /api/cloud/me
  • GET /api/cloud/subscription/plans
  • GET /api/cloud/quota
  • POST /api/cloud/ai/credential-leases
  • POST /api/cloud/ai/usage-reports

Boundaries​

  • /api/cloud/admin/* is operator-only and outside the public discovery scope
  • this page documents the stable public subset, not every internal route
  • automated clients should start from the API catalog and then follow service-desc and service-doc