Sweetmantech/myc 3899 docs mintlify first test doc get tasks#2
Conversation
Added the first real API endpoint from recoup-docs to test Mintlify setup:
- Added /api/accounts/{id} GET endpoint to OpenAPI spec
- Created Account and AccountResponse schemas
- Added accounts/get.mdx page
- Updated navigation with Accounts group
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
The accounts endpoint returned 404 because it doesn't exist on the API.
Switched to /api/tasks which exists on recoup-api.vercel.app:
- Updated server URL to recoup-api.vercel.app
- Replaced /api/accounts/{id} with /api/tasks (GET with query params)
- Added Task and TasksResponse schemas
- Updated navigation from Accounts to Tasks
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
📝 WalkthroughWalkthroughA new GET /api/tasks endpoint is introduced with complete OpenAPI specification including Task and TasksResponse schemas. Supporting documentation and navigation entries are added. The default API server URL is updated to the production environment. Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (2)
api-reference/openapi.json (2)
290-331: Consider addingrequiredfields to the Task schema.The
Taskschema defines all properties but doesn't specify which fields are required. This makes it unclear to API consumers which fields are guaranteed to be present in responses.Suggested improvement
"Task": { "type": "object", + "required": ["id", "title", "account_id"], "properties": { "id": {Adjust the required array based on which fields are actually guaranteed by the API implementation.
3-5: Update API info to reflect actual service.The
info.titleandinfo.descriptionstill reference "OpenAPI Plant Store" which is sample/placeholder content. Consider updating to reflect the actual Recoup API service for consistency.Suggested improvement
"info": { - "title": "OpenAPI Plant Store", - "description": "A sample API that uses a plant store as an example to demonstrate features in the OpenAPI specification", + "title": "Recoup API", + "description": "API for managing tasks and related resources", "license": {
📜 Review details
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (3)
api-reference/openapi.jsonapi-reference/tasks/get.mdxdocs.json
🔇 Additional comments (4)
api-reference/openapi.json (2)
13-13: Server URL updated to production.The server URL has been updated from the sandbox to the production API endpoint. This looks correct for the new Tasks API.
99-157: GET /api/tasks endpoint is well-documented.The endpoint definition includes clear descriptions for all query parameters with proper UUID format specifications. The response references are correctly structured.
api-reference/tasks/get.mdx (1)
1-4: LGTM!The MDX frontmatter correctly references the
GET /api/tasksendpoint defined in the OpenAPI spec. Mintlify will auto-generate the API documentation from the schema.docs.json (1)
59-64: LGTM!The new "Tasks" navigation group is correctly structured and positioned within the API reference tab. The page path matches the new MDX file location.
Triaged all 22 line-level comments (cubic-dev-ai + coderabbit). 7 implemented, 10 rejected with reason, 5 already-resolved by earlier PR commits. Implemented: #4 (skills/music-industry-research.mdx) — corrected `/research/*` to `/api/research/*` so the path matches the rest of the docs. #5 / #8 (api-reference/openapi/content.json:619) — POST /api/content/create description said "Returns `{run_id}`" but the 202 response and schema return `runIds` (an array). Brought the description into sync with the response shape so generated clients and readers stop targeting the wrong field name. #6 (authentication.mdx) — Bearer-token guidance was scoped to Privy JWTs only, but MCP clients also pass an API key as a Bearer token (per /mcp). Broadened the guidance and the comparison table row to cover both cases. #7 (agents.mdx Authenticate section) — auth steps walked through the email-verification flow as if it applied universally, but the documented throwaway agent+...@recoupable.com path returns the API key immediately on signup with no code. Added an explicit note up front and inline in step 1 that the agent+ path skips steps 2 and 3. #9 (api-reference/openapi/content.json POST /api/content/video description) — the description listed `prompt` as a mode for "create a video from a text description", but the ContentCreateVideoRequest schema requires `image_url` and explicitly says "text-only prompt mode is not supported." Rewrote the description to lead with the image_url requirement and updated each mode's gloss to reflect what the model actually does (uses the image as first frame / style ref / etc.). #15 (quickstart.mdx) — `jq -r .api_key` silently returns "null" on error responses (invalid code, expired code, rate limit) and exports RECOUP_API_KEY=null, which fails confusingly downstream. Switched to `jq -er '.api_key'` so the pipeline exits non-zero when the field is missing or null. #21 (credits.mdx Check your tier section) — documented `GET /api/subscription/status` and an `isPro` field. Verified live: endpoint returns 404 on api.recoupable.com AND on chat.recoupable.com, and isPro doesn't appear in any OpenAPI spec. The handler exists in chat/app/api/subscription/status/route.ts but isn't reachable as documented. Replaced the curl block with guidance to check the chat dashboard, with a note that a programmatic status endpoint is on the roadmap. Rejected with reason (10 comments): - #1, #3 (mcp.mdx, agents.mdx > 100 lines): an arbitrary lint rule that doesn't apply to docs pages whose value is enumeration (tool catalogs, decision trees) - #10 (releases.json profileUrls schema): real engineering question about whether to encode constraints in the schema; not a docs-only fix - #11 (docs.json primary color #0a0a0a): intentional brand refresh per merged PR #168 - #13 (docs.json primary CTA /keys subpath): matches the "Get API Key" CTA copy, not a generic app entrypoint - #16-#20 (kebab-case skill titles): explicit user choice; titles match URL slugs and the npx-skills `--skill <name>` install command Already resolved by earlier PR commits (5 comments): - #2, #12 (Instagram nav entries): removed in 318a555 - #14 (MCP host vs REST host): resolved in 1634ba6 — both on api.recoupable.com now - #22 (credits.mdx host): resolved in 1634ba6 — bot's recommended direction would have been backwards
Summary by CodeRabbit
New Features
GET /api/tasks) enables retrieval of tasks with optional filtering by task ID, account ID, or artist account ID.Documentation
Updates
✏️ Tip: You can customize this high-level summary in your review settings.