What Is programMembershipUsed Schema?

programMembershipUsed is the Schema.org property that connects a Reservation to the ProgramMembership applied to that reservation.

It can show that a frequent-flyer, hotel loyalty, rail club, rental, or other membership relationship was used for an actual booking. The subject is Reservation or a subtype, and the value is ProgramMembership. This edge is about application to a specific reservation; it does not define the loyalty program itself, the member’s tier, or a general promotional offer. Accurate use helps keep booking facts and membership facts connected without flattening them into text.

• Place programMembershipUsed on Reservation.
• Use ProgramMembership as the value.
• Model program, tier, and member facts on the membership node.

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.

Primary specification: Schema.org definition for programMembershipUsed.

programMembershipUsed records which membership was applied to one real reservation.

programMembershipUsed is used on Reservation, including reservation subtypes such as flights, lodging, trains, taxis, rentals, events, and dining where the property is inherited.

The page or message should describe an actual reservation, not a generic service or sales page. A hotel landing page offering rooms is not a LodgingReservation; a flight search result is not a FlightReservation. The property becomes appropriate when a specific booking exists and the membership was actually associated with it. Subject selection protects the graph from implying a customer transaction where none occurred.

1. Confirm the content represents an actual booking.
2. Select the correct Reservation subtype.
3. Create or reference the applied ProgramMembership.
4. Attach it through programMembershipUsed.

• 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

Use the property on real reservation records, never to turn availability or marketing content into a customer booking.

programMembershipUsed connects a Reservation to ProgramMembership, while program connects that ProgramMembership to MemberProgram.

The two properties form consecutive edges. A booking used a membership; the membership belongs to a loyalty program. Combining them allows one reservation to reference a customer-specific relationship without confusing the program entity with the account relationship. A reservation should not point directly to MemberProgram through programMembershipUsed, and a ProgramMembership should not use programMembershipUsed to name its program. Keeping the types correct also makes privacy decisions easier because program identity can be public while membership details may be private.

1. Reservation → programMembershipUsed → ProgramMembership.
2. ProgramMembership → program → MemberProgram.
3. MemberProgram → hostingOrganization → Organization.
4. Keep each node’s private and public fields separate.

• 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

The booking references a membership, and the membership separately references its program.

Any Reservation subtype inherits programMembershipUsed, so the implementation can cover travel, lodging, transport, dining, rental, and event bookings when a membership is truly applied.

FlightReservation and LodgingReservation are common loyalty cases, but TrainReservation, BusReservation, TaxiReservation, RentalCarReservation, EventReservation, and FoodEstablishmentReservation may also fit. The membership need not be a points program if it is a genuine club or membership relationship used in the booking. Do not invent a ProgramMembership for an email subscriber, coupon code, anonymous discount, or ordinary customer account unless it represents a real membership program.

• Flight and airline loyalty reservations.
• Hotel and accommodation member bookings.
• Rail, bus, taxi, or rental memberships.
• Dining and event club reservations.
• Other Reservation subtypes with a real applied membership.

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.

Reservation inheritance broadens coverage, but every use still needs evidence that a membership was applied.

Reservation JSON-LD should identify the booking, reference a ProgramMembership through programMembershipUsed, and limit customer-specific fields to what the private context requires.

An inline membership object can work in an authenticated confirmation or transactional message, while an @id reference can reduce duplication in a larger graph. The reservation may also include status, provider, reservationFor, bookingTime, underName, and reservationId. Do not copy every booking-system field into JSON-LD. Select only facts supported by the rendered confirmation and necessary for the experience, then inspect the final output with a controlled test reservation.

1. Declare the correct Reservation subtype.
2. Add core booking facts supported by the confirmation.
3. Connect the applied membership with programMembershipUsed.
4. Connect the membership to MemberProgram through program.
5. Validate rendered output with synthetic 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

A useful reservation graph connects the applied membership while keeping the booking payload deliberately small.

Privacy should prevent membership numbers, balances, personal identities, and booking details from appearing in public pages or unnecessary machine-readable payloads.

Reservations are individual transactional records. They can combine dates, routes, hotels, events, member status, confirmation codes, and identity data into a sensitive profile. Transactional email or authenticated account markup may have legitimate functionality, but inclusion still needs minimization and access control. Public SEO pages should use service, offer, organization, and program entities instead of fabricating or publishing reservations. Never place membership numbers or reservation tokens in URLs, canonical tags, analytics events, or public JSON-LD.

• Keep real reservation markup off public marketing pages.
• Omit membershipNumber unless a private use is necessary.
• Use synthetic data in documentation and testing.
• Prevent booking and member identifiers from reaching analytics.
• Review email forwarding and cache exposure.

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.

Structured reservation data should never expand the audience for membership or itinerary information.

Partner and codeshare bookings should reference the ProgramMembership actually applied, not whichever airline, hotel, broker, or marketplace logo dominates the confirmation.

A booking may involve a seller, broker, operating provider, loyalty host, and redemption partner. Those roles are different. If a traveler enters Program A’s membership and the reservation records it, reference that membership even when Partner B operates the service. Do not infer application merely because the traveler could earn points. The confirmation, account activity, or reservation record should show that the membership was attached.

1. Identify the seller, provider, and operating party.
2. Confirm which membership is recorded on the booking.
3. Connect that ProgramMembership to its actual MemberProgram.
4. Avoid claiming points or benefits not shown in the reservation.

• 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

Partner complexity changes business roles, but the property still follows the membership actually applied to the reservation.

Common errors include using the property on offers, pointing directly to MemberProgram, inventing memberships, exposing identifiers, and retaining stale links after booking changes.

A canceled or modified reservation may no longer carry the same membership. Template code can also copy a logged-in account membership into every reservation even when the booking was made without it. Another failure is modeling a coupon, card payment, email account, or ordinary customer record as ProgramMembership. Type validation catches a direct MemberProgram value, but only real booking evidence can prove the membership was applied.

• Property placed on Offer or a generic service page.
• MemberProgram used instead of ProgramMembership.
• Logged-in membership assumed to apply to every booking.
• Membership number exposed in confirmation HTML.
• Canceled or changed booking retains stale membership data.

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.

Correct types are essential, but the booking record must also prove that the membership was actually used.