Skip to content

Commit e3bca70

Browse files
piyalbasuclaudeJakeUrbanCassioMG
authored
Add Freighter developer documentation (#1)
* Add Freighter developer documentation Migrate docs from freighter-integration-docs, removing unused GitBook assets. Includes developer guide, mobile integration, and API reference. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Address PR review feedback: fix broken links, wrong paths, and browser compat issues - Fix mobile/ link to mobile/README.md for GitBook/docsify compatibility - Replace undocumented signBlob with signMessage in import example - Standardize on @stellar/stellar-sdk (not js-stellar-sdk or stellar-sdk) - Fix broken soroban-development.md link to point to Stellar developer docs - Fix CDN paths from dist/ to build/ to resolve 404s - Correct setAllowed() return type description to { isAllowed: true } - Clarify chainId is a top-level WalletConnect request field, not inside params - Replace Buffer.from() with TextEncoder/atob for browser compatibility - Use consistent client.request() variable name in auth entry example - Pin docsify (4.13.1) and prismjs (1.29.0) CDN versions Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix error type: error is FreighterApiError object, not string The actual @stellar/freighter-api returns error as a FreighterApiError object with { code, message, ext? }, not a plain string. Updated all return type signatures and code examples to use error.message. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix mobile signing docs to match freighter-mobile source - Blockaid site scan happens at connection time, not at auth-entry signing time - Add missing "non-string" condition to signAuthEntry error table Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Rewrite introduction and add Stellar Wallets Kit integration - Rewrote README.md with What You Can Build, How It Works, and Why Freighter sections to walk developers through the integration experience without code samples - Added Stellar Wallets Kit (stellarwalletskit.dev) to the Introduction and Integrations page for multi-wallet support Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Note that Stellar Wallets Kit is desktop-only Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix missed error.message in reading-data.md and docsify CDN 404 - reading-data.md: console.error(error) -> console.error(error.message) to match FreighterApiError object type (missed in earlier update) - index.html: docsify path dist/ -> lib/ to fix 404 Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Update README.md Co-authored-by: Jake Urban <10968980+JakeUrban@users.noreply.github.com> * Update developer-guide/signing.md Co-authored-by: Jake Urban <10968980+JakeUrban@users.noreply.github.com> * Rename developer-guide/ to extension/ Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Reduce redundant non-custodial/user-control messaging in intro Define non-custodial once in the opening line and remove repeated references to private key handling and user control throughout the page. Addresses PR review feedback. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Emphasize in-app browser WalletConnect flow over QR code scanning The primary mobile use case is the in-app browser where WalletConnect shows a wallet selection panel, not QR scanning. QR is now mentioned as a secondary desktop-to-mobile option. Addresses PR review feedback. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix Stellar Wallets Kit description: it supports mobile via WalletConnect Removes incorrect "desktop only" note. Addresses PR review feedback. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Rewrite Why Freighter to differentiate vs other Stellar wallets Focus on what sets Freighter apart from Lobstr, xBull, etc: SDF-maintained, most advanced feature set (custom tokens, auth entry inspection, message signing, Blockaid scanning), desktop + mobile. Addresses PR review feedback. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Replace "Choose Your Integration" with straightforward Get Started links Extension is the only option for desktop, WalletConnect is the only option for mobile — there's no real choice. Simplified to direct links per platform. Addresses PR review feedback. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Remove recommendation label from requestAccess() Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Add context for why dapps need addToken Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Align token terminology with Stellar developer docs Replace "Soroban token" and "custom token" with "contract token" to match developers.stellar.org nomenclature. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Rename extension overview title to Extension Integration Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Move import examples from extension overview to installation page Addresses PR feedback that the overview references freighter-api imports before the reader has been through installation. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Move dual-integration guidance to Get Started, remove inaccurate details Removed the "Supporting Both Extension and Mobile" section from the mobile overview (contained inaccurate window.freighterApi reference). Added a concise "Both" option to the Get Started section instead. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Add hint that isConnected can detect desktop vs mobile Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix inconsistencies between extension and mobile docs 1. "dApp" -> "Dapp" in mobile/installation.md (consistent with rest) 2. Network table: "Mainnet" -> "Mainnet (PUBLIC)" to map to enum value 3. "Pubnet's passphrase" -> "Mainnet passphrase" in token-management 4. Mobile connecting title: "Connecting" -> "Connecting to Freighter Mobile" 5. Added note about different response field names between extension and mobile (signedTxXdr vs signedXDR, signedMessage vs signature) 6. Clarified SEP-43 reference in mobile API table 7. Added error tables to extension signing methods (matching mobile) 8. Aligned parameter/example headings to bold text (matching mobile) 9. SUMMARY.md: "Extension" -> "Extension (freighter-api)" for symmetry 10. Added full connect-sign-submit example to mobile signing Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix isConnected hint and mobile full example requiredNamespaces - isConnected() hint: clarify it checks for extension installation, not mobile detection. Point to window.stellar?.platform for that. - Mobile signing full example: add all 4 methods to requiredNamespaces (was missing stellar_signMessage and stellar_signAuthEntry). Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Apply Cassio's review feedback on WalletConnect docs - Fix WalletConnect docs links to point to docs.walletconnect.network/app-sdk/overview (the .com URL routes to WalletConnect Pay) - Rename WalletConnect Cloud to WalletConnect Dashboard with new dashboard.walletconnect.com URL - Note that Stellar Wallets Kit's WC module only supports 2 of 4 Freighter Mobile signing methods Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Migrate mobile docs to @walletconnect/universal-provider (#2) * Migrate mobile installation to @walletconnect/universal-provider Replace @walletconnect/sign-client with @walletconnect/universal-provider in installation instructions. Add Stellar Wallets Kit alternative note and link to Reown docs. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Migrate mobile connecting to UniversalProvider Replace SignClient connect/event/disconnect patterns with UniversalProvider equivalents. Add public key extraction example. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Migrate mobile signing examples to UniversalProvider Replace all client.request() calls with provider.request() pattern. Update full connect-sign-submit example. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Remove isFreighterInAppBrowser branching from full example The in-app browser detection is a Stellar Wallets Kit implementation detail, not needed by dapp developers using UniversalProvider directly. Simplified the full example and clarified the in-app vs external browser UX difference in prose instead. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Add AppKit modal for wallet selection and QR code display - Add @reown/appkit to installation alongside universal-provider - Initialize createAppKit with manualWCControl for standalone modal - Use modal.open({ uri }) in display_uri handler instead of console.log - Add links to Reown UniversalProvider and AppKit modal docs Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Clarify that wallet selection triggers deep-linking Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Clarify that QR code and wallet list are in the same modal Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Pass universalProvider to createAppKit Wire the provider to the modal via the universalProvider option, matching the pattern from the Reown migration guide. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix review issues: modal API, imports, and cross-file clarity Critical: - Replace display_uri + modal.open({ uri }) with modal.open() before provider.connect() — AppKit handles URI display automatically when manualWCControl and universalProvider are set Important: - Add comment explaining mainnet placeholder in AppKit networks config - Fix README chainId hint to reference provider.request() argument - Add session null check after provider.connect() Suggestions: - Switch to named import { UniversalProvider } matching Reown docs - Add cross-file reference notes to connecting.md and signing.md Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Fix: use namespaces instead of requiredNamespaces for UniversalProvider UniversalProvider.ConnectParams does not accept requiredNamespaces — the correct field is namespaces. Passing requiredNamespaces was silently ignored, meaning the Stellar namespace would not be registered. Also added a note explaining that UniversalProvider treats namespaces as optional on the first connection (they become required on reconnections via storage). dApps should verify session.namespaces.stellar.methods after connecting. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> * Address Jake's review feedback - Clarify requestAccess() does full Allow List authorization, not just public key access - Remove internal password/caching details from signing docs (not actionable for dapps) - Add note that addToken() will become a no-op once auto-detect ships - Remove "Building the entryXdr" section from mobile signing (out of scope) Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Co-authored-by: Jake Urban <10968980+JakeUrban@users.noreply.github.com> Co-authored-by: Cássio Marcos Goulart <3228151+CassioMG@users.noreply.github.com>
1 parent fff4be9 commit e3bca70

16 files changed

Lines changed: 1127 additions & 2 deletions

.gitbook.yaml

Lines changed: 5 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,5 @@
1+
root: ./
2+
3+
structure:
4+
readme: README.md
5+
summary: SUMMARY.md

README.md

Lines changed: 56 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -1,2 +1,56 @@
1-
# freighter-developer-docs
2-
Freighter wallet developer documentation
1+
# Welcome to Freighter
2+
3+
Freighter is a non-custodial wallet for the Stellar network, available as a browser extension and a mobile app. Non-custodial means your users hold their own keys — your dapp never sees or stores private keys. This guide walks you through integrating Freighter so your users can connect their wallets, sign transactions, and interact with Soroban smart contracts.
4+
5+
## What You Can Build
6+
7+
With Freighter, your dapp can connect a user's wallet with a single call — no signup form, no password, just a familiar wallet popup and an immediate public key. From there you can read their active network, hand off transactions for signing, and submit to the network.
8+
9+
For dapps that integrate with smart contracts, Freighter also handles authorization entry signing for smart contract calls and arbitrary message signing for account verification.
10+
11+
## How It Works
12+
13+
The integration model is simple: your dapp talks to the wallet, and the wallet talks to the user.
14+
15+
For **desktop browsers**, you integrate with the Freighter extension through a lightweight JavaScript library. It injects itself into the page, and your dapp calls methods like "is the wallet connected?", "what's the user's address?", and "please sign this transaction."
16+
17+
For **mobile**, the integration works over WalletConnect v2. When a user opens your dapp in a mobile browser, WalletConnect presents a modal where they select Freighter as their wallet and approve the connection. On desktop, the same flow can display a QR code for the user to scan. Either way, a secure relay session is established and signing requests flow through the same pattern — your dapp proposes, the user reviews and approves in the wallet.
18+
19+
Both paths produce the same output: signed transactions you can submit to the Stellar network. So your backend and submission logic stay the same regardless of whether your user connected from a laptop or a phone.
20+
21+
If you want to support multiple Stellar wallets — not just Freighter — take a look at [Stellar Wallets Kit](https://stellarwalletskit.dev/). It provides a unified interface across Stellar wallets, including browser extensions and WalletConnect-based mobile wallets, so your users can connect with whichever wallet they prefer.
22+
23+
> **Note:** Stellar Wallets Kit's WalletConnect module currently only exposes `stellar_signXDR` and `stellar_signAndSubmitXDR`. If your dapp needs `stellar_signMessage` or `stellar_signAuthEntry` against Freighter Mobile, integrate WalletConnect directly for now (tracked in [stellar/freighter-mobile#815](https://github.com/stellar/freighter-mobile/issues/815)).
24+
25+
## Why Freighter
26+
27+
**Built and maintained by SDF.** Freighter is developed by the Stellar Development Foundation, the same team behind the core Stellar protocol and SDKs.
28+
29+
**Complete Stellar support.** Transaction signing, Soroban authorization entry signing with contract invocation inspection, SEP-53 message signing, contract token management, and Blockaid transaction scanning.
30+
31+
**Desktop and mobile.** Browser extension for desktop, WalletConnect for mobile. Both paths produce the same signed output, so your dapp supports both with minimal branching.
32+
33+
## Get Started
34+
35+
**Desktop** — integrate with the Freighter browser extension using `@stellar/freighter-api`. See the [Extension Guide](extension/installation.md).
36+
37+
**Mobile** — connect to Freighter Mobile over WalletConnect v2. See the [Mobile Guide](mobile/README.md).
38+
39+
**Both** — if your dapp needs to support desktop and mobile users, use both integration paths. Both produce the same output (signed XDR), so your submission logic stays the same regardless of how the user connected.
40+
41+
## Quick links
42+
43+
| I want to... | Extension | Mobile |
44+
| ------------------------------------- | -------------------------------------------------- | ---------------------------------------------------- |
45+
| Install / set up | [Installation](extension/installation.md) | [Installation](mobile/installation.md) |
46+
| Connect to Freighter | [Connecting](extension/connecting.md) | [Connecting](mobile/connecting.md) |
47+
| Sign a transaction | [Signing](extension/signing.md) | [Signing](mobile/signing.md) |
48+
| Add a token | [Token Management](extension/token-management.md) ||
49+
50+
## Resources
51+
52+
- [GitHub — Freighter Extension](https://github.com/stellar/freighter)
53+
- [GitHub — Freighter Mobile](https://github.com/stellar/freighter-mobile)
54+
- [Chrome Extension Store](https://chromewebstore.google.com/detail/freighter/bcacfldlkkdogcmkkibnjlakofdplcbk)
55+
- [Stellar Developer Docs](https://developers.stellar.org)
56+
- [WalletConnect v2 Docs](https://docs.walletconnect.network/app-sdk/overview)

SUMMARY.md

Lines changed: 24 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,24 @@
1+
# Table of contents
2+
3+
* [Introduction](README.md)
4+
5+
## Extension (freighter-api)
6+
7+
* [Installation](extension/installation.md)
8+
* [Overview](extension/README.md)
9+
* [Connecting](extension/connecting.md)
10+
* [Reading Data](extension/reading-data.md)
11+
* [Signing](extension/signing.md)
12+
* [Token Management](extension/token-management.md)
13+
* [Watching Changes](extension/watching-changes.md)
14+
15+
## Mobile (WalletConnect)
16+
17+
* [Installation](mobile/installation.md)
18+
* [Overview](mobile/README.md)
19+
* [Connecting](mobile/connecting.md)
20+
* [Signing](mobile/signing.md)
21+
22+
## Integrations
23+
24+
* [Third-Party Integrations](integrations/README.md)

extension/README.md

Lines changed: 27 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,27 @@
1+
# Extension Integration
2+
3+
Integrate Freighter into your web application using `@stellar/freighter-api`. This library lets you send and receive data from a user's Freighter extension.
4+
5+
`@stellar/freighter-api` adheres to the [SEP-43](https://github.com/stellar/stellar-protocol/blob/master/ecosystem/sep-0043.md) standard for wallet interfaces on Stellar, and also offers additional methods beyond the spec such as `getNetworkDetails`, `addToken`, and `WatchWalletChanges`.
6+
7+
## Error Type
8+
9+
All methods return an optional `error` field of type `FreighterApiError`:
10+
11+
```typescript
12+
interface FreighterApiError {
13+
code: number;
14+
message: string;
15+
ext?: string[];
16+
}
17+
```
18+
19+
## API Reference
20+
21+
| Category | Description |
22+
| --- | --- |
23+
| [Connecting](connecting.md) | Detect Freighter, check permissions, request access |
24+
| [Reading Data](reading-data.md) | Get the user's address and network configuration |
25+
| [Signing](signing.md) | Sign transactions, auth entries, and messages |
26+
| [Token Management](token-management.md) | Add contract tokens to the user's wallet |
27+
| [Watching Changes](watching-changes.md) | Monitor wallet state changes in real time |

extension/connecting.md

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
# Connecting to Freighter
2+
3+
Detect whether a user has Freighter installed, check if your app is authorized, and request access to the user's public key.
4+
5+
## Detecting Freighter
6+
7+
### `isConnected()`
8+
9+
Check if the user has Freighter installed in their browser.
10+
11+
**Returns:** `Promise<{ isConnected: boolean } & { error?: FreighterApiError }>`
12+
13+
```typescript
14+
import { isConnected } from "@stellar/freighter-api";
15+
16+
const result = await isConnected();
17+
18+
if (result.isConnected) {
19+
console.log("Freighter is installed");
20+
}
21+
```
22+
23+
{% hint style="info" %}
24+
`isConnected()` checks whether the Freighter extension is installed. Note that it returns `false` for any user without the extension — not just mobile users. To detect Freighter Mobile's in-app browser specifically, check for `window.stellar?.platform === "mobile"`.
25+
{% endhint %}
26+
27+
## Checking Authorization
28+
29+
### `isAllowed()`
30+
31+
Check if the user has previously authorized your app to receive data from Freighter.
32+
33+
**Returns:** `Promise<{ isAllowed: boolean } & { error?: FreighterApiError }>`
34+
35+
```typescript
36+
import { isAllowed } from "@stellar/freighter-api";
37+
38+
const result = await isAllowed();
39+
40+
if (result.isAllowed) {
41+
console.log("App is on the Allow List");
42+
}
43+
```
44+
45+
## Requesting Authorization
46+
47+
### `setAllowed()`
48+
49+
Prompt the user to authorize your app and add it to Freighter's **Allow List**. Once approved, the extension can provide user data without additional prompts.
50+
51+
**Returns:** `Promise<{ isAllowed: boolean } & { error?: FreighterApiError }>`
52+
53+
```typescript
54+
import { setAllowed } from "@stellar/freighter-api";
55+
56+
const result = await setAllowed();
57+
58+
if (result.isAllowed) {
59+
console.log("App added to Allow List");
60+
}
61+
```
62+
63+
{% hint style="info" %}
64+
If the user has already authorized your app, `setAllowed()` resolves immediately with `{ isAllowed: true }`.
65+
{% endhint %}
66+
67+
## Requesting Access
68+
69+
### `requestAccess()`
70+
71+
Prompt the user to add your dapp to Freighter's Allow List and return their public key in one call. This is the recommended way to connect — it combines authorization and data retrieval in a single step.
72+
73+
**Returns:** `Promise<{ address: string } & { error?: FreighterApiError }>`
74+
75+
If the user has previously authorized your app, the public key is returned immediately without a popup.
76+
77+
```typescript
78+
import { isConnected, requestAccess } from "@stellar/freighter-api";
79+
80+
// Always check isConnected first
81+
const connectResult = await isConnected();
82+
if (!connectResult.isConnected) {
83+
console.error("Freighter is not installed");
84+
return;
85+
}
86+
87+
const accessResult = await requestAccess();
88+
if (accessResult.error) {
89+
console.error("Access denied:", accessResult.error.message);
90+
} else {
91+
console.log("Public key:", accessResult.address);
92+
}
93+
```
94+
95+
{% hint style="warning" %}
96+
Always check `isConnected()` before calling `requestAccess()` to ensure the extension is available.
97+
{% endhint %}
98+
99+
## Next steps
100+
101+
Once connected, you can [read the user's address and network](reading-data.md) or [sign transactions](signing.md).

extension/installation.md

Lines changed: 85 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,85 @@
1+
# Installation
2+
3+
Get up and running with Freighter by installing the browser extension and choosing the right integration method for your app.
4+
5+
## Prerequisites
6+
7+
1. Install the [Freighter browser extension](https://chromewebstore.google.com/detail/freighter/bcacfldlkkdogcmkkibnjlakofdplcbk) from the Chrome Web Store.
8+
2. Choose an integration method below based on your project setup.
9+
10+
## Choose Your Integration
11+
12+
### npm / yarn
13+
14+
Use this when building with a bundler (Webpack, Vite, etc.) in a React, Next.js, or other modern JS framework.
15+
16+
**Ideal for:**
17+
18+
- React, Vue, Svelte, or Angular applications
19+
- Server-side rendered apps (Next.js, Nuxt)
20+
- Any project using a JavaScript bundler
21+
22+
```bash
23+
npm install @stellar/freighter-api
24+
```
25+
26+
```bash
27+
yarn add @stellar/freighter-api
28+
```
29+
30+
Then import in your code. You can import the entire library:
31+
32+
```javascript
33+
import freighterApi from "@stellar/freighter-api";
34+
```
35+
36+
Or import only what you need:
37+
38+
```javascript
39+
import {
40+
isConnected,
41+
getAddress,
42+
signAuthEntry,
43+
signTransaction,
44+
signMessage,
45+
addToken,
46+
} from "@stellar/freighter-api";
47+
```
48+
49+
> See the [Extension Integration](../extension/) for the full API reference.
50+
51+
### CDN (script tag)
52+
53+
Use this for plain HTML pages or projects without a build step. The library is loaded directly in the browser.
54+
55+
**Ideal for:**
56+
57+
- Static HTML sites
58+
- Prototypes and quick experiments
59+
- Projects without a bundler
60+
61+
Add to your `<head>`:
62+
63+
```html
64+
<script src="https://unpkg.com/@stellar/freighter-api/build/index.min.js"></script>
65+
```
66+
67+
This always loads the latest version automatically. To pin a specific version:
68+
69+
```html
70+
<script src="https://unpkg.com/@stellar/freighter-api@6.0.1/build/index.min.js"></script>
71+
```
72+
73+
Then access the API via `window.freighterApi`:
74+
75+
```javascript
76+
const { address } = await window.freighterApi.requestAccess();
77+
```
78+
79+
## Next steps
80+
81+
| I want to... | Go to |
82+
| ------------------------------------- | -------------------------------------------------------- |
83+
| Connect my app to Freighter | [Connecting](../extension/connecting.md) |
84+
| Sign a transaction | [Signing](../extension/signing.md) |
85+
| Add a token | [Token Management](../extension/token-management.md) |

extension/reading-data.md

Lines changed: 71 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,71 @@
1+
# Reading Data
2+
3+
Retrieve the user's public key and network configuration from Freighter.
4+
5+
{% hint style="info" %}
6+
These methods require that the user has previously authorized your app via [`requestAccess()`](connecting.md#requesting-access) or [`setAllowed()`](connecting.md#requesting-authorization).
7+
{% endhint %}
8+
9+
## Getting the User's Address
10+
11+
### `getAddress()`
12+
13+
A lightweight way to retrieve the user's public key. Unlike `requestAccess()`, this will **not** prompt the user — it returns an empty string if the app isn't authorized or Freighter isn't connected.
14+
15+
**Returns:** `Promise<{ address: string } & { error?: FreighterApiError }>`
16+
17+
```typescript
18+
import { getAddress } from "@stellar/freighter-api";
19+
20+
const { address, error } = await getAddress();
21+
22+
if (error) {
23+
console.error(error.message);
24+
} else {
25+
console.log("Public key:", address);
26+
}
27+
```
28+
29+
## Getting the Network
30+
31+
### `getNetwork()`
32+
33+
Get the name and passphrase of the network the user has selected in Freighter.
34+
35+
**Returns:** `Promise<{ network: string; networkPassphrase: string } & { error?: FreighterApiError }>`
36+
37+
Possible `network` values: `PUBLIC`, `TESTNET`, `FUTURENET`, or `STANDALONE` (custom networks).
38+
39+
```typescript
40+
import { getNetwork } from "@stellar/freighter-api";
41+
42+
const { network, networkPassphrase, error } = await getNetwork();
43+
44+
if (!error) {
45+
console.log("Network:", network); // e.g., "TESTNET"
46+
console.log("Passphrase:", networkPassphrase);
47+
}
48+
```
49+
50+
### `getNetworkDetails()`
51+
52+
Get comprehensive network configuration including the Horizon URL, passphrase, and Soroban RPC URL.
53+
54+
**Returns:** `Promise<{ network: string; networkUrl: string; networkPassphrase: string; sorobanRpcUrl?: string } & { error?: FreighterApiError }>`
55+
56+
```typescript
57+
import { getNetworkDetails } from "@stellar/freighter-api";
58+
59+
const details = await getNetworkDetails();
60+
61+
if (!details.error) {
62+
console.log("Network:", details.network); // e.g., "TESTNET"
63+
console.log("Horizon:", details.networkUrl); // e.g., "https://horizon-testnet.stellar.org"
64+
console.log("Passphrase:", details.networkPassphrase);
65+
console.log("Soroban RPC:", details.sorobanRpcUrl); // e.g., "https://soroban-testnet.stellar.org"
66+
}
67+
```
68+
69+
{% hint style="info" %}
70+
Use `getNetworkDetails()` instead of `getNetwork()` when working with Soroban smart contracts or when you need specific network endpoints.
71+
{% endhint %}

0 commit comments

Comments
 (0)