[Help wanted] Hotelbeds Activities/Transfers: cancellation policy + ON_REQUEST confirmation reality

[telivity-otaip]

Who this is for

OTA lodging / activities integrators who have shipped Hotelbeds (or similar bedbanks) and know how ON_REQUEST, net vs selling, and cancellation classes actually behave in sandbox vs live.

Why this hardens the system

Open DOMAIN_QUESTIONs in the KB / mappers:

Activities (docs/knowledge-base/activities.md, packages/adapters/hotelbeds/src/activities-mapper.ts):

• DQ-A2 net vs selling rate
• DQ-A3 ON_REQUEST confirmation / poll cadence
• DQ-A5 cancellation policy structure (NOR/NRF vs stepped penalty list)

Transfers (docs/knowledge-base/transfers.md):

• DQ-T2 GPS code format
• DQ-T3/T5 time + timezone
• DQ-T4 per-vehicle vs per-pax pricing
• DQ-T6 ON_REQUEST
• DQ-T7 net vs selling

Wrong answers here = wrong cancel penalties and stuck bookings.

What we need

1. Close as many DQ-A* / DQ-T* items as you can from official docs or live/sandbox observation (cite which).
2. Update KB "Open DOMAIN_QUESTIONs" → CLOSED with evidence.
3. Adjust mappers + add adapter tests with recorded fixtures (redact keys).

Acceptance criteria

• Each resolved DQ cites source (URL / doc section / observed response shape)
• Mapper behavior matches documented structure
• Fixtures for cancellation + ON_REQUEST paths
• Unresolved items stay explicitly open — no guessing

Search keywords

help wanted · Hotelbeds · activities · transfers · ON_REQUEST · cancellation policy · OTA · lodging

How to contribute

Sandbox response samples (sanitized) in comments are gold. KB close-out PRs welcome per DQ.