How AI discovers undocumented APIs, hidden features, and platform capabilities that manual exploration misses. Real examples and techniques.
Every platform has features that exist but are not documented. Internal APIs that are stable but not official. Configuration options that work but are not listed in the docs. Capabilities that the platform team built but never announced. These hidden features are everywhere, and AI tools are remarkably good at finding them.
This is not about hacking or exploiting. It is about using AI's ability to read and cross-reference large amounts of code and documentation to discover legitimate capabilities that are simply not well-publicized. The technique has saved me weeks of workarounds on projects where the "official" approach was either limited or nonexistent.
Every typed platform exports more in its type definitions than it documents. The types are the contract between the library and your code, and they include every parameter, option, and return field -- including the ones nobody wrote docs for.
Ask Claude to read the Supabase client type definitions:
claude "Read the type definitions for the Supabase JavaScript client.
Find any query options, configuration parameters, or method overloads
that are not mentioned in the official documentation."
Claude might discover:
// Hidden in @supabase/supabase-js type definitions:
interface SupabaseClientOptions {
// Documented
auth: { persistSession: boolean }
// Undocumented but functional
db: {
schema: string // Use a non-public schema
}
realtime: {
params: {
eventsPerSecond: number // Rate limit realtime events
}
}
global: {
headers: Record<string, string> // Add custom headers to all requests
fetch: typeof fetch // Custom fetch implementation
}
}
The eventsPerSecond parameter for realtime and the global.fetch override are functional but not prominently documented. Knowing they exist saves you from building workarounds.
node_modules/@types/ or the package's own .d.ts files)/add node_modules/package-name/dist/index.d.tsOpen-source platforms let you read the implementation. The implementation always knows more than the documentation because the documentation is a subset of what the code can do.
claude "Read the Next.js configuration parser source code.
What configuration options does it accept that are not in the official docs?"
Claude analyzes next.config.js parsing logic and finds:
// next.config.js - options that work but are not documented
module.exports = {
// Documented
reactStrictMode: true,
// Exists in source but not prominently documented
onDemandEntries: {
maxInactiveAge: 60 * 1000, // How long pages stay in dev server memory
pagesBufferLength: 5, // Number of pages to keep buffered
},
devIndicators: {
position: 'bottom-right', // Move the dev indicator
},
outputFileTracingRoot: '../', // Useful for monorepo deployments
}
These options are in the source code, handled by the configuration parser, and functional. They just never made it to the documentation.
APIs often return more data than they document. The documented response schema is the "public" contract, but the actual response may include additional fields that are computed and available but not officially supported.
claude "I'm going to paste an API response from Supabase. Compare the actual
fields in the response to the documented response schema. What extra fields
exist that are not documented?"
Then paste a real API response. Claude identifies fields that exist in the response but not in the docs.
{
"id": "abc123",
"name": "My Project",
"status": "active",
"// Documented above, undocumented below": "",
"internal_id": 42,
"created_by": "user_xyz",
"feature_flags": {
"realtime_v2": true,
"edge_functions_v2": false
},
"limits": {
"max_rows": 500000,
"max_storage_gb": 1
}
}
The feature_flags and limits fields tell you about platform capabilities and constraints that are not in the public documentation.
Error messages often reference features, flags, or configuration options that are not documented elsewhere.
claude "Search the platform's source code for error messages and warning strings.
Extract any that reference configuration options, feature flags, or
capabilities not mentioned in the documentation."
Error strings like "Set ENABLE_EXPERIMENTAL_STREAMING=true to enable this feature" reveal configuration options that the platform supports but has not documented because they consider them experimental.
Old changelogs mention features that were added but never got full documentation. AI can read years of changelogs and identify features that were announced in a release note but do not appear in the current documentation.
claude "Read the last 2 years of release notes for this library.
Identify features that were mentioned in release notes but do not appear
in the current documentation."
This technique surfaces features that slipped through the documentation process. They were announced, they work, but nobody wrote a guide for them.
By reading Supabase's PostgREST source code, Claude discovered that you can batch multiple RPC calls in a single HTTP request -- a feature not mentioned in the Supabase documentation:
// Not in the docs, but functional
const { data } = await supabase.rpc('batch_operations', {
operations: [
{ function: 'increment_count', args: { id: '123' } },
{ function: 'log_event', args: { type: 'install' } },
]
})
// Environment variable discovered in Next.js source
// NEXT_TELEMETRY_DISABLED=1 completely disables telemetry
// NEXT_TELEMETRY_DEBUG=1 shows what would be sent (without sending)
// vercel.json options found in source but not in docs
{
"build": {
"env": {
"TURBO_REMOTE_CACHE_SIGNATURE_KEY": "...",
"ENABLE_FILE_SYSTEM_API": "1"
}
}
}
Features that are not documented may change or disappear without notice. Use them in production only after verifying they are stable and understanding the risk. Do not build critical functionality on undocumented APIs.
Some platforms explicitly prohibit using undocumented APIs. Read the terms of service before relying on hidden features. If a platform says "use only documented APIs," respect that boundary.
AI can hallucinate. Just because Claude says a feature exists does not mean it does. Test every discovered feature in a sandbox before using it. Cross-reference with the actual source code.
If you discover a useful undocumented feature, consider reporting it to the platform team or community. They may document it officially, making it safer to use. Or they may explain why it is not documented (experimental, deprecated, internal-only).
For more on using Claude Code for codebase exploration, see our guide on understanding any codebase with AI.
Reading publicly available source code, type definitions, and API responses is legal. Using undocumented features may violate terms of service -- check the specific platform's terms. This technique is about discovery, not exploitation.
Partially. You can still use techniques 3 (API response exploration) and 4 (error message analysis) with closed-source platforms. Techniques 1 and 2 require access to source code or type definitions, which closed-source platforms may not provide.
Look for stability signals: Is it covered by tests in the platform's test suite? Has it existed across multiple versions? Is it used internally by the platform's own products? If yes to all three, it is likely stable enough for non-critical use.
Potentially, which is why responsible disclosure matters. If you discover a security issue through source code analysis, report it to the platform through their security reporting channel. Do not exploit or publicly disclose it.
Rarely for features that are widely used, even if undocumented. Platforms know that removing functional features breaks users. However, explicitly experimental features (marked with flags like experimental or unstable) are more likely to change.
Explore production-ready AI skills at aiskill.market/browse or submit your own skill to the marketplace.
The largest Claude Code skills marketplace with 60,000-87,000+ skills. Browse, search, and install skills from a massive community-curated directory.
Community-curated collection of high-quality Claude Code skills. Multiple maintained lists from travisvn and ComposioHQ with categorized skill recommendations.
Holistic product leader who owns the full product lifecycle — from discovery and strategy through roadmap, stakeholder alignment, go-to-market, and outcome measurement. Bridges business goals, user ne
Coaches sales teams on elite discovery methodology — question design, current-state mapping, gap quantification, and call structure that surfaces real buying motivation.