docs: document EXACT_OUTPUT support for bridging

[vezzabel]

Summary

• trade-types.mdx: Broadens the EXACT_OUTPUT section to include bridging and payment use cases. Previously, the recommendation was scoped exclusively to destination calls (e.g. minting with an exact ERC20 amount). Engineering confirmed EXACT_OUTPUT is also supported for plain bridging.
• bridging-integration-guide.mdx: Adds an explicit trade type selection guide at the top of the "Get a Quote" step, with a description of all three supported trade types (EXACT_INPUT, EXPECTED_OUTPUT, EXACT_OUTPUT) and a second curl example showing an EXACT_OUTPUT bridge quote request alongside the existing EXACT_INPUT example.

What changed and why

EXACT_OUTPUT was previously described only as a feature for cross-chain destination calls. This left a documentation gap where developers using the bridging integration guide had no visibility into EXACT_OUTPUT as an option, and the trade-types reference page actively directed readers away from using it for bridges. The deposit addresses page compounds this by noting EXACT_OUTPUT is only supported on strict deposit addresses, which could be misread as a global restriction rather than one scoped to the deposit address flow.

---

Generated by Claude Code

[github-actions]

Claude finished @vezzabel's task in 1m 41s —— View job

---

Code Review — PR #356

• Read the diff against origin/main
• Review trade-types.mdx changes
• Review bridging-integration-guide.mdx changes
• Check CLAUDE.md compliance
• Post review findings

---

Summary: This is a clean, well-scoped docs PR. Broadening EXACT_OUTPUT beyond destination calls to cover bridging/payments reads clearly, and the new trade-type list + second curl example are a nice addition to the bridging guide. No blocking issues found. One minor, optional observation below.

✅ Correctness & style

• trade-types.mdx — The reworded recommendation is accurate and well-phrased. cross-chain stays hyphenated/lowercase per §5, and trailing whitespace was cleaned up. 👍
• bridging-integration-guide.mdx — The trade-type intro list uses bold + backticks (EXACT_INPUT) matching the §2.9 prose convention, links to the trade-types concept page on first mention (§2.6), and the two request tabs are genuinely isolated scenarios, so the multi-tab <CodeGroup> is compliant with §2.8 ("tabs show genuinely isolated scenarios"). The new curl block is self-contained and pastable.

💡 Minor (optional)

Shared Response tab now only reflects EXACT_INPUT. The <CodeGroup> has two request tabs (EXACT_INPUT, EXACT_OUTPUT) but a single Response tab (bridging-integration-guide.mdx:59-121). That response shows currencyIn.amount = 100000000000000000 (exact input) and a variable, smaller currencyOut.amount = 95000000000000000. A reader who selects the EXACT_OUTPUT request tab and then the shared Response may be confused, since for EXACT_OUTPUT the output should be the exact 100000000000000000 and the input is what varies (larger). Not a blocker — the tabs render independently — but you may want to either note that the response corresponds to the EXACT_INPUT request, or leave a short comment clarifying it. Purely a clarity nit.

Notes (not flagged — pre-existing / out of scope)

• trade-types.mdx:6 uses lowercase backticked values (exact_input, ...) while the section bodies use uppercase — pre-existing, untouched by this PR.
• The user field uses a hardcoded address rather than a WALLET_ADDRESS placeholder (§2.8), but this mirrors the existing EXACT_INPUT example, so it's consistent with the surrounding page.

Nothing here needs to block merge. Nice, targeted documentation fix.

[mintlify]

Preview deployment for your docs. Learn more about Mintlify Previews.

Project	Status	Preview	Updated (UTC)
unevenlabs	🟢 Ready	View Preview	Jul 6, 2026, 9:50 PM

💡 Tip: Enable Workflows to automatically generate PRs for you.

[vezzabel]

TL;DR I was chatting with Deor and Rory in the solving channel and we didn't explicitly highlight that integrators can use exact_output for bridging, propose updating our docs to reflect this more explicitly.