Define the authorized interface
Share an official agent or MCP interface where available, otherwise an official API or approved partner integration. Define the permitted discovery, comparison, refresh and handoff actions separately. An affiliate or deep-link agreement is not automatically permission for automated browser access.
Relay uses structured authorized interfaces and validates API credentials, scopes and rate limits for its own requests. Browser continuation belongs to the assistant. Sourced explicit agent restrictions appear as advisory metadata; missing policy does not block a handoff.
Set the access policy
The ProviderAccessPolicy keeps Relay API controls separate from agent policy observations. Agent observations record a status, summary, source and review date. At handoff, restrictions are advisory only and the assistant controls the next step.
Relay API permissions are action-specific: search access does not enable booking, and a test account does not enable live transactions. These API controls do not enforce the assistant's independent browser behavior. A handoff does not claim provider approval.
Tell Relay how the agent must identify itself, which endpoints or paths it may use, what data it may retain, and how policy changes or revocation should be communicated. Preserve your authentication boundary. Relay does not need your customers' passwords or card details for ordinary discovery and handoff preparation.
Expose useful capabilities
Document supported markets, geography, categories, dates, request limits, filters and response fields. Identify whether the interface returns an item, an offer, a property preview, a selected rate, a quote or confirmed inventory.
Provide stable provider identifiers, currencies, price basis, fees and taxes, freshness timestamps, expiry, availability semantics, attribution and a permitted next action. Missing information stays unknown. Supply validation errors, rate-limit behavior and test fixtures without customer secrets.
The current connectors distinguish preparation from execution. Add native transactions only through an explicitly approved integration with user approval, idempotency, reconciliation and provider confirmation.
Control traffic and freshness
Agree request budgets, burst limits, concurrency and retry behavior. Relay should reuse valid structured results and avoid unnecessary repeated searches and availability polling. Rate limits belong to the provider policy, not a model's instructions.
Define caching and retention by data class. A cached result must retain its age and expiry. Permission to view data does not imply permission to store it indefinitely or reuse it across customers. Refresh prices and availability where the action requires it.
Preserve attribution and economics
ProviderCommercialPolicy is separate from access permission. It records the supported referral or commission model, attribution method, eligibility, approved destinations and commercial restrictions. Organic ranking must not depend on commission.
Discovery and monetization sources may differ. Before handoff, Relay resolves an eligible attributed path where available and preserves the provider's attribution exactly. It must not bypass checkout, booking or fulfillment economics. Useful permitted discovery is not blocked solely because no commission agreement exists.
Validate the connection
Confirm authorized distribution and supported assistant actions. Test normalization, errors, throttling, expiry and permitted handoff paths. Verify attribution through an approved test flow. Agree production enablement and a contact for incidents or policy updates.
Provider account and approval details remain private operational records. Public documentation describes capabilities without implying that an unverified partnership is approved.