# How to Spot Hallucinated APIs in Code

> Find invented or mismatched APIs in proposed code by checking imports, installed versions, signatures, and failure behavior instead of trusting familiar names.

- Canonical HTML: [https://unrust.dev/use-cases/spot-hallucinated-apis](https://unrust.dev/use-cases/spot-hallucinated-apis)
- Markdown representation: [https://unrust.dev/use-cases/spot-hallucinated-apis/index.md](https://unrust.dev/use-cases/spot-hallucinated-apis/index.md)

Published: 2026-07-14

## Direct answer

Spot a hallucinated API by checking the proposal against the installed package and the exact version your project uses. Verify the import path, method name, parameter shape, return type, and error behavior at the call site. A method that sounds likely can still be absent, deprecated, available only in another version, or incompatible with the surrounding code's runtime assumptions.

## Verify the source before adapting the call

Do not repair an unfamiliar call by guessing at a nearby API. Start with the package lockfile, local type definitions, generated docs, or official documentation for the version in use. That check is usually faster than building a chain of compensating changes around an invented method.

## Check the boundary created by the call

Even a real method can be used incorrectly. Confirm what it accepts, whether it returns a value or promise, how it signals failure, and whether the proposal handles the result according to the codebase's conventions. Imports and types are evidence, not a substitute for a behavior check.

## Practice loop

1. For an unfamiliar call, locate its installed declaration or official documentation before editing arguments.
2. Compare the documented return and failure behavior with the branch that consumes it.
3. Add a focused test or type check that would fail if the method or signature were wrong.

## Limits of this page

Documentation and type declarations can still lag behind deployment configuration, feature flags, or runtime permissions. This page gives a verification habit, not a guarantee that one session can measure API knowledge or explain why a proposed call initially seemed believable.

## Source context

Editorially reviewed for Unrust using public language documentation, common code-review practice, and small original examples written for this resource system.

## Related resources

- [How to Review AI-Generated Code Safely](https://unrust.dev/use-cases/review-ai-generated-code/index.md): Use a contract-first review loop to inspect AI-generated code, test risky boundaries, and decide whether a proposed change is ready to merge.
- [Reviewing AI-Generated Python Code](https://unrust.dev/languages/python/reviewing-ai-generated-code/index.md): Review AI-generated Python by checking mutation, exception handling, dependency APIs, and data validation against the application's actual behavior and local conventions.

Next step: [Take the free diagnostic](https://unrust.dev/diagnostic/index.md)