[Bug] API Key identity limitations found on comments and versions endpoints during automated E2E testing

[mihailt]

Hello IcePanel team! 👋

First off, huge fan of the product! To push the boundaries of AI agent architecture integrations, I built an open-source MCP server that natively wraps this exact icepanel-js client (repo: mihailt/ice-panel-mcp-server). Specifically, I developed a custom codegen pipeline leveraging TypeScript AST reflection to parse your SDK typings and dynamically auto-generate the complete suite of Zod validation schemas and MCP tool proxies, completely automating your catalog into an AI context that successfully runs locally or serverless on Cloudflare using SSE.

To ensure the SDK wrapper was rock solid, I set up 100% test coverage and ran live automated E2E tests executing structurally against the live IcePanel API. During the suite of 48 exhaustive assertions, the tests organically identified two specific endpoint edge cases explicitly related to how purely API Keys handle user identity logic.

I currently have these skipped securely in my E2E suite, but wanted to flag them cleanly for your team:

1. delete_comments_replies

• Error: Throws a 401 Unauthorized ("Comment reply was created by another user").
• Context: It appears the backend lacks identity tracking when authenticated exclusively via API Keys on this nested route, making it impossible to natively delete a reply inherently created by the exact same API key.
• Reference: Skipped E2E Assertion here

2. create_versions_reverts

• Error: Throws a 422 Unprocessable Entity ("User not provided").
• Context: Restoring a spatial version seems to logically demand a user demographic profile seamlessly attached to the request that API Keys do not inherently possess geographically.
• Reference: Skipped E2E Assertion here

Steps to Reproduce

You can view the exact execution payloads and natively run the skipped E2E assertions directly from my repository linked above securely. The conditionally skipped actions are explicitly documented both in the test suite and directly within our README.

Let me know if you need me to pull any specific logs from my test iterations to universally help patch these API Key perimeter limitations. Thanks for building such an explicitly awesome tool!