Partner links and wallet tools: URL, deep link, or integration?

A partner URL, a wallet deep link, and an integration can all send someone toward the same app, but they solve different jobs. The difference is whether you are passing context, opening a connection flow, or building a supported software boundary.

Compare the three shapes

Shape	What it carries	What it does not establish
Partner URL	A destination and optional attribution marker	Wallet connection, attribution, or activity
Deep link	A request to open an app or connection flow	Signature, transaction result, or provider support
Integration	A defined API, SDK, or MCP contract	Permission to perform an unreviewed side effect

A URL is usually the smallest implementation. It can be copied into a newsletter or community post, but it should be treated as discovery until the service records an explicit wallet connection. A deep link can reduce navigation friction, yet its availability varies by wallet and host. An integration requires documented schemas, error states, versioning, and a support owner.

Draw the signing boundary

For a wallet action, the integration should stop before the user’s authorization point unless the product has a separately documented, approved flow. A read endpoint can return public status. A review endpoint can prepare an app route. A quote can show current terms. The wallet still needs to display the final transaction and the user needs to approve it.

The participant agent kit is a concrete example of a bounded contract. Its six tools read public health, stage, wallet history, Desk, or partner data. suibrokers_prepare_action returns a review-only plan with prefill: false and an exact app route. It does not quote, build, sign, send, activate a referral, boot a wallet, or mint an NFT. A partner implementing another tool should publish the same boundary in its schema and documentation.

Decide what to document

For a URL, document the destination, the marker’s meaning, and the fact that opening a link is not attribution. For a deep link, document accepted schemes, fallback behavior, and the screen the user should see. Do not claim that every wallet or region supports the same link.

For an integration, document:

• accepted input formats and canonicalization;
• response fields, source timestamps, and state values;
• authentication and origin checks;
• rate, body, and response-size limits;
• errors and retry behavior;
• side effects, if any, and the approval step;
• version and deprecation policy.

Use a primary source for every external wallet or provider claim. The MCP connection guide is useful when the integration is an MCP server rather than a direct SDK.

Test with harmless fixtures

Start with a status read and an invalid input. Verify that the integration rejects malformed wallets and coin types without calling a write endpoint. Then test a valid review plan and confirm that it contains no query parameters or prefilled transaction values. Record the origin and asOf timestamp in the fixture.

The right partner choice depends on the job. Use a URL for a simple, visible route. Use a deep link when the host documents the opening flow. Build an integration when you need a stable, testable contract. In every case, keep attribution, signing, and confirmed ledger results as separate events.