docs: update documentation for AppKit 1.8.19 changes

[devin-ai-integration]

Description

Updates documentation to reflect changes introduced in AppKit 1.8.19. The release included three changes:

1. fetchWallets expanded options (#5526): The useAppKitWallets hook's fetchWallets method now accepts additional options (search, entries, badge, include, exclude). The query parameter is deprecated in favor of search.
2. wcError exposed on useAppKitWallets (#5548): A new wcError boolean return value indicates WalletConnect URI fetch failures.
3. caipAddress and chainId on allAccounts (#5535): Each account in allAccounts now includes caipAddress (CAIP-10 format) and chainId. The Connection.accounts type also gains caipAddress.

Files changed

• appkit/react/early-access/headless.mdx — Added wcError return field, updated fetchWallets type signature with full FetchWalletsOptions interface, updated code examples from query → search
• appkit/react/core/hooks.mdx — Updated allAccounts description, added explicit Account type definition, added caipAddress to Connection.accounts
• appkit/next/core/hooks.mdx — Same allAccounts and Account type updates as React
• appkit/vue/core/composables.mdx — Added previously-missing allAccounts to returns list with updated description
• appkit/react-native/core/hooks.mdx — Updated allAccounts description

Updates since last revision

• Inlined BadgeType to 'none' | 'certified' in the FetchWalletsOptions interface so the type is self-contained in the docs
• Reordered wcError ResponseField to appear immediately after wcUri, matching the destructuring example order

Human review checklist

• Verify the Account type definition matches source at packages/controllers/src/utils/TypeUtil.ts (the path field for Bitcoin was intentionally omitted as internal)
• Confirm adding allAccounts to Vue composables returns list is appropriate (it was previously undocumented)
• Verify FetchWalletsOptions field types/descriptions match source at packages/controllers/exports/react.ts
• Check that 'none' | 'certified' accurately represents the BadgeType union

Requested by: unknown ()
Link to Devin Session

Tests

• - Ran the changes locally with Mintlify and confirmed that the changes appear as expected.
• - Ran a grammar check on the updated/created content using ChatGPT.

Direct link to the deployed preview files

• React Headless (useAppKitWallets)
• React Hooks (useAppKitAccount)
• Next.js Hooks (useAppKitAccount)
• Vue Composables (useAppKitAccount)
• React Native Hooks (useAccount)

[devin-ai-integration]

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

• Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
• Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

• Disable automatic comment and CI monitoring

[claude]

Claude finished @devin-ai-integration[bot]'s task in 2m 14s —— View job

---

🤖 PR Review

• Gather context (CLAUDE.md, tone of voice guide, changed files)
• Analyze changed files
• Run breaking changes subagent
• Post final review

---

No breaking changes detected. All documented API changes are additive (new optional parameters/fields, deprecation with backward compat).

Found 2 issue(s)

Issue 1: BadgeType referenced but not defined

ID: headless-badge-type-undefined-a3f1
File: appkit/react/early-access/headless.mdx (within FetchWalletsOptions interface)
Severity: MEDIUM
Category: code_quality

Context:

• Pattern: badge?: BadgeType is used in the interface definition but BadgeType is never defined or explained in the docs.
• Risk: Developers reading the docs won't know what valid values are for badge without digging into source code.
• Impact: Poor developer experience — the type appears undefined in context.
• Trigger: Any developer trying to use the badge parameter.

Recommendation: Inline the union type instead of referring to BadgeType:

/** Filter wallets by badge type */
badge?: 'none' | 'certified'

Fix this →

---

Issue 2: wcError ordering in Returns section doesn't match destructuring example

ID: headless-wcerror-order-mismatch-b7c2
File: appkit/react/early-access/headless.mdx:37 vs :89
Severity: LOW
Category: code_quality

Context:

• Pattern: The destructuring example at line 37 shows ..., wcUri, wcError, connectingWallet, ... but the Returns section documents wcError after count (after connectingWallet, page, count).
• Risk: Developers scanning the Returns section to find wcError will find it in an unexpected position relative to the example.
• Impact: Minor confusion when cross-referencing the example with the field descriptions.

Recommendation: Move the wcError ResponseField to appear immediately after the wcUri field in the Returns section, to match the destructuring example order.

Fix this →