Add Travel Rule documentation

[Prado]

Add Travel Rule documentation

https://uphold.atlassian.net/browse/BKO-6717
https://uphold.atlassian.net/browse/BKO-6718

[Copilot]

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Adds documentation for the Travel Rule API so integrators can retrieve pending request details and submit the required information to proceed with withdrawals.

Changes:

• Added a new Travel Rule documentation page with endpoint descriptions.
• Included example curl requests and example JSON response including formSchema.
• Documented request/response expectations and basic authorization/ownership notes.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Both notices mention authentication/authorization but the docs don’t specify the expected error codes for common failure modes (e.g., missing/invalid token likely 401, valid token but not owner likely 404 as stated). Consider explicitly documenting the expected status codes per case to reduce integration ambiguity (and keep it consistent between GET and POST sections).

[Copilot]

The POST example uses a beneficiaryAccountNumber value that looks like a crypto address (0x...), which may confuse integrators if the field is meant to be an account number distinct from an address (especially since there is also beneficiaryAddress). Consider adjusting the example values to clearly differentiate these fields (e.g., a numeric/IBAN-style account number vs. a postal address), or rename/clarify the field meaning in the schema description if beneficiaryAccountNumber can indeed be an on-chain address.

Suggested change

	-d '{ "beneficiaryAccountNumber": "0x1234abcd", "beneficiaryAddress": "123 Main St", "beneficiaryCountry": "US", "beneficiaryName": "Jane Doe" }'
	-d '{ "beneficiaryAccountNumber": "ACC-123456789", "beneficiaryAddress": "123 Main St", "beneficiaryCountry": "US", "beneficiaryName": "Jane Doe" }'

[Copilot]

It’s unclear which JSON Schema dialect/version formSchema follows (draft-04/draft-07/2019-09, etc.). Since validators and tooling differ by draft, consider stating the schema version used (e.g., via $schema or in prose) or explicitly noting that the returned schema is compatible with a specific draft.