Per-Rider Waivers for Groups

For a group booking with quantity > 1, you usually want each rider to sign their own waiver. Per-rider links create N separate signed_agreements rows, one per rider, each with its own typed name and signature.

When to use per-rider

• Insurance requires individual liability waivers for each rider
• Separate adult vs minor signatures (parent signing for child)
• Tour groups where each rider should personally acknowledge the rules
• Corporate outings where each employee signs their own waiver

If all of the above don't apply, a single per-reservation waiver (signed by the lead booker) is fine.

How to issue per-rider links

For a group of 4:

POST /api/reservations/[id]/agreements
{
  "templateId": "...",
  "isPerRider": true,
  "riderIndex": 0
}

POST /api/reservations/[id]/agreements
{
  "templateId": "...",
  "isPerRider": true,
  "riderIndex": 1
}

POST /api/reservations/[id]/agreements
{
  "templateId": "...",
  "isPerRider": true,
  "riderIndex": 2
}

POST /api/reservations/[id]/agreements
{
  "templateId": "...",
  "isPerRider": true,
  "riderIndex": 3
}

The booking now has 4 pending waivers, each with its own token.

A "Issue per-rider waivers (N riders)" button on the booking detail page is on the roadmap.

What riders see

The signing page detects is_per_rider and shows a small "Rider X of Y" badge:

Rental Agreement

[Booking #1234]
Pickup 5/15 at 10 AM

Rider 1 of 4 of group booking
For: Jane Smith

The rider knows which slot they're filling. They sign with their own typed name; the signature row is bound to that rider_index.

How operators verify

The booking detail page shows N "Signed" badges, one per signed waiver. Each row shows:

• Template name
• "Rider X" annotation
• Signed by (typed name)
• Signed at (timestamp)

Until all N are signed, you can see how many are still pending and who hasn't signed.

To pull the audit trail:

SELECT
  rider_index,
  typed_name,
  signed_at,
  signer_ip
FROM signed_agreements
WHERE reservation_id = '<reservation-id>'
  AND is_per_rider = true
ORDER BY rider_index;

Workflow at the counter

For a group of 4 arriving at your shop:

1. Create the group booking (quantity = 4)
2. Issue 4 per-rider waiver links via the API
3. Print the 4 QR codes onto a single sheet of paper, or display them sequentially on the iPad
4. Hand each rider their QR code
5. Each rider scans, signs on their phone
6. Refresh the booking detail page — verify 4 signatures
7. Hand over the bikes

Workflow for online group bookings

If a group books online (currently the public page only supports quantity=1, so this is uncommon):

1. The lead booker receives the confirmation email with their manage-link
2. Operator pre-issues per-rider waiver links via the API or the booking detail page
3. Lead booker forwards each link to the corresponding rider via email/SMS
4. Each rider signs on their own time before pickup day

What the rider_index represents

It's just a label — 0, 1, 2, 3 for the four riders in the group. No enforcement that "rider 0 must sign first" or "rider_index must match a specific person."

If you want to track which rider is which, capture their names in the agreement template's variables (e.g., {{rider_1_name}}, {{rider_2_name}}) and have the lead booker fill them in pre-signing.

Per-rider with different templates

If adults and minors need different waivers, issue different templates per riderIndex:

POST /api/reservations/[id]/agreements
{ "templateId": "<adult-template-id>", "isPerRider": true, "riderIndex": 0 }

POST /api/reservations/[id]/agreements
{ "templateId": "<minor-template-id>", "isPerRider": true, "riderIndex": 1 }

This way rider 0 signs the adult waiver and rider 1 (a minor) signs the parental-consent waiver.

What's NOT enforced

• You can issue any number of per-rider links — even more than the reservation's quantity. The system doesn't enforce a 1:1 ratio.
• Riders aren't required to sign in order — riderIndex 3 can sign before riderIndex 0.
• Multiple riders can use the same link — but only the first to submit "wins"; the second sees "already signed" and the data is bound to whoever signed first.

These are operational guardrails for the operator to enforce, not the system.

Common pitfalls

Rider signs the wrong link

The typed name reveals it. If rider 1 (Sara) signed link 2 (intended for Tom), the audit log shows "rider_index=1, typed_name=Sara." You can either accept it (the waiver is still valid) or void and re-issue.

Lead booker signs all 4 themselves

Visible in the audit log — all 4 signatures are "John Smith" with the same IP. Per your policy, you may need each rider's actual signature. If the lead booker is signing on behalf of a minor, that's fine — for adults, you may need to re-issue.

Customer abandons mid-group-signing

You have 2 of 4 signed. The reservation is still active. You can:

• Wait for the remaining signers to complete (no rush — links last 7 days)
• Force-cancel the booking and refund if the trip won't happen
• Convert the partial signatures to a single "lead booker" waiver if legal allows