Add buyer seat ID and name to get_products and create_media_buy requests

[Kat-swivel]

Summary

Add standard fields for buyer seat identification to get_products and create_media_buy requests. This would enable sales agents to distinguish between different advertisers, clients, or business units using the same authentication credentials.

Motivation

Currently, AdCP authentication identifies the buyer organization but doesn't provide a standard way to identify specific seats within that organization. This creates challenges for:

• Agency relationships: An agency representing 20 advertisers uses one auth token, but publishers can't tell which end advertiser is making each request
• Holding companies: Multiple trading desks or divisions within one buyer organization
• Seat-level business rules: Publishers may need to apply pricing, products, or restrictions based on the specific advertiser, not just the buyer org
• Reporting and reconciliation: Matching AdCP transactions to seat-level billing and analytics
• Brand safety: Publishers may have competitive separation or category exclusions at the advertiser level

Proposed Solution

Add optional fields to identify the buyer seat:

{
  "buyer_seat_id": "agency-x-client-123",
  "buyer_seat_name": "Acme Corporation"
}

Fields:

buyer_seat_id (string, optional): Unique identifier for the buyer seat within the authenticated buyer organization
buyer_seat_name (string, optional): Human-readable name of the buyer seat
Requests to include these fields:

get_products - Allows sales agents to return seat-specific products or pricing
create_media_buy - Associates the media buy with a specific seat for reporting and billing

Design Considerations

1. Optional vs Required: Should likely be optional to maintain backward compatibility. Many buyers have 1:1 org-to-seat relationships.
3. Relationship to auth: These fields work alongside existing authentication. Auth still identifies the buyer org; seat fields provide finer granularity.
5. Validation: Sales agents could validate that the provided seat ID is authorized for the authenticated buyer org.
7. OpenRTB parallel: Similar to OpenRTB's wseat field in bid requests, which serves the same purpose.

Additional Context

This would particularly benefit:

• Agency holding companies managing multiple client relationships
• Publishers who need seat-level deal management
• Platforms transitioning from programmatic (where seat IDs are standard) to agentic

Questions for Discussion

• Should these fields be optional or required?
• Should there be a registry or validation mechanism for seat IDs?
• Are there other requests beyond get_products and create_media_buy that would benefit from seat identification?
• Should we support multiple seats per request, or always one seat?