What Is broker Schema?

The broker schema property identifies the Organization or Person that arranges an exchange between a buyer and seller, usually without acquiring or releasing ownership of the product or service.

It models an intermediary role. Booking platforms, real estate brokers, insurance marketplaces and service platforms may arrange transactions while another party sells or provides the item. If the entity is actually the seller or buyer and the intermediary role is unclear, use the clearer participant role instead.

Schema.org allows broker on Invoice, Order, Reservation and Service. It accepts Organization or Person and supersedes bookingAgent. The page should visibly explain the arrangement before the relationship is published.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Use broker only for real intermediaries.
• Prefer seller or buyer when the role is clearer.
• Require public first-party relationship evidence.

Primary specification: Schema.org definition for broker.

broker schema should identify the party arranging an exchange, not simply the website hosting the page.

The broker property is supported on Invoice, Order, Reservation and Service, with an Organization or Person as its value.

On Reservation, broker can identify the booking intermediary. On Service, it can identify a platform or professional arranging access to the provider. On Invoice and Order, it records the intermediary associated with the documented transaction.

Do not place broker directly on Product, Offer, WebPage or Organization. First identify the supported transaction or service entity. A marketplace homepage is not enough evidence that every listing has the marketplace as broker.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify the supported parent entity.
2. Confirm an exchange is arranged.
3. Name the responsible intermediary.
4. Keep seller and provider relationships separate.

Correct parent context shows which reservation, service, order or invoice the broker helps arrange.

broker arranges the exchange between buyer and seller, while seller is the party offering goods or services for sale, lease, lending or loan.

A marketplace may connect a buyer to an independent merchant without becoming the merchant. The listing’s Offer names the seller; a supported Service, Order or Reservation may identify the platform as broker when the transaction model proves that role.

Some platforms are merchants of record and therefore may be sellers, not merely brokers. Read checkout, invoice and contractual disclosures. The seller schema guide covers merchant identity and Offer placement.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Trace the contracting merchant.
• Trace the party arranging the match.
• Do not label every marketplace as broker automatically.

Seller makes the commercial offer; broker facilitates the exchange between transaction parties.

The broker arranges an exchange, the provider delivers or performs the service, and an agent may act on behalf of another party in a broader action relationship.

A home-services platform may broker the booking while a local contractor provides the repair. A real estate professional may broker a transaction without providing the property. The word “agent” in visible business language does not automatically map to a generic Schema.org agent relationship or broker role.

Use the actual commercial function rather than job title alone. The provider schema guide explains fulfillment responsibility.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Map who arranges the exchange.
2. Map who fulfills the item.
3. Map who sells or contracts.
4. Assign only relationships the page proves.

Broker, provider and agent express different responsibilities even when one professional appears in several roles.

Use Organization when a marketplace, brokerage or company arranges the exchange, and Person when a named individual personally acts as the broker.

A travel platform or insurance brokerage is normally an Organization. An individually licensed real estate broker may be Person when the page and transaction identify that individual. A staff member displayed on a company page is not automatically the broker if the firm owns the client relationship.

Choose the responsible intermediary entity and reuse a stable @id. Do not add license numbers, personal addresses or regulatory claims unless they are publicly supported and appropriate.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Follow contractual intermediary responsibility.
• Use the most specific Organization subtype available.
• Protect personal data and avoid inference.

The broker value should name the entity accountable for arranging the exchange, whether a company or individual.

Add broker by referencing the intermediary’s Organization or Person identity from the supported Service or Reservation, while separately identifying the provider, seller and reservation details.

A stable @id avoids duplicate platform identities across many listings. The parent page should show that the intermediary arranges the transaction and not merely advertises or links to it. Keep commercial terms attached to the seller or Offer that owns them.

{
  "@type": "Service",
  "name": "Residential Plumbing Repair",
  "broker": {
    "@type": "Organization",
    "@id": "https://marketplace.example/#organization",
    "name": "Example Service Marketplace"
  },
  "provider": {
    "@type": "LocalBusiness",
    "name": "Example Plumbing Company"
  }
}

The broker and provider are intentionally separate nodes because arranging and performing the service are different facts.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Identify the supported parent.
2. Create or reuse canonical broker identity.
3. Connect distinct commercial roles.
4. Validate the full rendered graph.

A clear broker relationship preserves the intermediary role without hiding who sells or performs the service.

A transaction can involve multiple intermediaries, but publish multiple broker values only when each party genuinely arranges the exchange and the page clearly discloses those roles.

Complex real estate or insurance transactions may involve cooperating brokers. Travel bookings can pass through affiliate and booking platforms, but an affiliate that only refers traffic may not be a broker in the actual reservation.

Model the relationship at the most specific supported Order, Reservation, Invoice or Service. Avoid a long chain of platforms inferred from tracking URLs, redirects or payment processors.

1. Identify the exact page, asset, entity or relationship described in this section.
2. Inspect the live implementation and retain the observed evidence.
3. Compare the observation with the intended meaning and its primary specification.
4. Correct any mismatch, then retest the live result.
5. Record the accountable owner and review date.

• Require disclosed exchange-arranging responsibility.
• Scope brokers to the correct transaction.
• Do not infer roles from technical routing.

Multiple brokers are appropriate only when every named party materially arranges the same exchange.

Common broker mistakes include labeling the seller or provider as broker without evidence, treating any marketplace or affiliate as an intermediary, using the superseded bookingAgent property, duplicating identities and applying one platform broker sitewide.

Validation confirms Organization or Person is an allowed value but cannot prove the intermediary role. Marketplace business models differ: some platforms broker, some sell, some provide and some combine roles. Read first-party transaction disclosures.

Sitewide defaults are dangerous when a marketplace hosts direct-sold, brokered and third-party offers together. The broker relationship must come from transaction-level data.

• The exact page, asset, entity or relationship covered by this section
• The live implementation rather than an editor-only preview
• The primary specification or first-party record defining the expected behavior
• The validation result, accountable owner and review date

1. Confirm the parent type.
2. Verify exchange-arranging evidence.
3. Compare seller and provider roles.
4. Repair the source of repeated defaults.

Broker markup is accurate only when the intermediary role is explicit, current and attached to the right transaction.