Seat Assignment API
What does a "Seat Assignment API" do? And when it does that, on whose behalf does it do it?
Maybe you've heard the API acronym in various descriptions. The Hopscotch Seat Assignment API determines the best seat matches based on your seating preference, seating availability, historical activity and the probability of your getting a particular seat.
Introductory concepts were written up in previous posts (here, here and here). We had to first understand why the existing systems neglected this type of transaction. It turned out that the preference engine model was complex, let alone creating a system to actually provide a solution. And on a full flight at that. Imagine what we can do once integrated with a seat assignment system.
We considered how airline reservation and checkin systems separate the behind-the-scene operations from you, the passenger. Likewise, we designed a two-way interface to unify seat assignment with passenger seating preferences while keeping these interfaces separate and optional.
We also researched the available options for passengers seeking to change seats on a full flight. Those finding themselves in this situation may choose to interact with airline representatives or other passengers, as described in this previous post. We spot-checked our own flights to see how exchanging seats with another passenger was possible.
Designing a third party interface as an API with distinct boundaries and integration points provided a better option to maintain separation of problem domains. This separation of domains achieved our overarching design goal of returning high quality matches via a real-time interface without interfering with airline and airport operations or FAA manifest regulations.
Maybe you've heard the API acronym in various descriptions. The Hopscotch Seat Assignment API determines the best seat matches based on your seating preference, seating availability, historical activity and the probability of your getting a particular seat.
Introductory concepts were written up in previous posts (here, here and here). We had to first understand why the existing systems neglected this type of transaction. It turned out that the preference engine model was complex, let alone creating a system to actually provide a solution. And on a full flight at that. Imagine what we can do once integrated with a seat assignment system.
Seat (Re-)Assignment API
The Hopscotch Seat Assignment API provides a computerized interface for exchanging information with another computer. Calling our API as an external and isolated system means it can support :- Passenger electronic check-in via mobile app,
- Computer systems like autonomous seat assignment systems,
- Passengers with a bar coded boarding pass (IATA's BCBP format),
- Airlines and online checkin websites, and
- Other API's.
![]() |
Service Animal: "May I Have My Preferred Seat Now?" |
System Actors
"Figure 1: User and System Actors" shows a UML model of actors in a seat assignment system. The UML design method keeps the developers focused on users and how they use our system. Use cases described in the next section are how your mobile app or another computer uses our API.![]() |
Figure 1: User and System Actors |
We considered how airline reservation and checkin systems separate the behind-the-scene operations from you, the passenger. Likewise, we designed a two-way interface to unify seat assignment with passenger seating preferences while keeping these interfaces separate and optional.
Airline Use Cases
Our API can be deployed this way to avoid dependencies on legacy data systems, although it can perform data lookups via the Passenger Name Record Code, pnrcode. That "pnrcode" is what you see labeled as your confirmation number used to find your reservation and by airport security checkpoints. The SeatBot generates new seating suggestions by merging passenger preferences with seat locations. It could deliver these to you, the individual passenger, or to your airline.We also researched the available options for passengers seeking to change seats on a full flight. Those finding themselves in this situation may choose to interact with airline representatives or other passengers, as described in this previous post. We spot-checked our own flights to see how exchanging seats with another passenger was possible.
Designing a third party interface as an API with distinct boundaries and integration points provided a better option to maintain separation of problem domains. This separation of domains achieved our overarching design goal of returning high quality matches via a real-time interface without interfering with airline and airport operations or FAA manifest regulations.
Comments
Post a Comment