Reading a reseller booking email is a parsing problem, and it never stays solved

Automatic booking capture gets sold as an integration. Most of it is text handling, and text handling stops working the day a reseller edits their own confirmation template.

That is not a criticism of anybody's engineering. It is the shape of the problem. The only real design decision is what the system does on the morning it no longer understands an email it understood yesterday: guess quietly, or refuse loudly.

What actually arrives

In most reseller relationships nothing arrives on a wire. An email arrives.

A customer books on a comparison site in June. That site's system sends a confirmation to the car park, laid out the way that system lays things out, from whatever address that system sends from. No schema, no version number, no technical contract. A subject line, a body, and somebody's idea of how to write a date.

Some channels do better. Parkos exposes an API we pull on a cursor, merchant by merchant, with an overlap window so a booking amended during a sync is not missed. Solution Park is reached through a polling bridge that still signs in against an HTML login form, sits behind a flag that is off by default, and is documented internally as something to retire. That is the honest description of a legacy integration that works. The rest is email, plus a nightly CSV where a reseller will produce one.

Four paths, one booking record

Whatever the path, the output has to be identical. A booking captured from an email, pulled from an API, imported from a CSV or typed at the counter has to produce the same record, with the same fields, attributed to the source it came from.

That matters more than it sounds. The commission rate sits on the pairing of a car park and a booking source, so source attribution is what makes revenue by channel mean anything six months later. Clean ingestion makes the analytics free. Sloppy ingestion puts the same error into every number downstream.

The record has to carry a plate, a model, a colour, an arrival and a departure flight number, a passenger count, an amount already paid, a balance due on site and whatever options the reseller sold. Not out of greed. The driver at 05:00 needs the colour and the desk at 22:00 needs the balance.

Six things a parser has to get right

The sender. A whitelist of exact addresses, not domains. Resellers push transactional mail through marketing platforms, so the real sending address is often a subdomain nobody mentioned, and a domain level rule is wide enough to let a forged confirmation through. Exact addresses are more annoying and they are the right call.

The reference. Idempotent upsert on the car park, the source and the reference number. The same booking will be delivered twice. It will also be delivered again, amended, three weeks later, and the amendment sometimes lands before the original because a mail relay held one of them.

The plate. The same channel sends AB-123-CD, AB123CD and ab 123 cd in the same week. Store what arrived, normalise what you index, and never confuse the two. An operator searching for a plate at the barrier is not going to type the hyphens.

The name. Jean-Philippe Bérard arrives as BERARD JEAN PHILIPPE, as J.P. Berard and as Jean Philippe Berard, across three messages on the same account. That is why matching two bookings on a name is a trap and why the reference is the key. It is also why a camera does not solve this: ANPR reads the plate perfectly and still cannot tell you which of those three spellings booked it.

The dates. Wall clock local time with no offset, which is what almost every reseller sends. 03/04 is the third of April here and the fourth of March to a parser written elsewhere. A stay that straddles the last Sunday in October runs an hour longer than a naive subtraction says, and that Sunday is also the busiest return weekend of the autumn.

The duplicate. Dedupe on the message id first, on a hash of the body second. The second rule exists because a forwarded copy carries a different message id and identical content, and because some senders retry with a fresh id after a timeout.

Refusing is cheaper than guessing, and here is the arithmetic

Example figures. A 400 space car park, 900 bookings a month, 60 per cent through resellers, 300 of them from one channel. On a Tuesday that channel changes a label in its template from Registration to Vehicle reg. Nobody is told, because from their side nothing happened.

The parser that guesses. It writes the booking with an empty plate. Bookings arrive an average of 21 days before the stay, so the first symptom is a car at the kerb whose record has no plate, three weeks later. By then roughly 210 bookings carry the same hole, and somebody spends a day re-keying plates out of 210 archived emails while the fortnight runs.

The parser that refuses. It cannot fill a required field, so it does not apply the booking. Fourteen intake records appear that same morning, each holding the raw email and the reason. Someone opens one, sees the label, the adapter changes by one line, and the fourteen are reprocessed before lunch. Nothing reached the operational queue in a state anybody had to trust.

Same bug, same day, two different mornings. That is the whole argument.

The queue that catches the rest, and the four moves that empty it

Anything that cannot be applied safely is held, not dropped. This is the part of a capture pipeline worth asking about, because it only exists if somebody decided it should.

An intake record keeps the raw message and the reason it failed. A person has four moves:

• Promote it into a booking, once the missing piece is supplied.
• Reprocess it, which is what you do after fixing the adapter, so yesterday's failures replay against today's code.
• Whitelist the sender, which is the answer when a reseller moved to a new sending address.
• Dismiss it, which is the answer for a marketing email that reached the intake address.

Nothing disappears silently and nothing enters the day's work by assumption. A booking the system is unsure about is worth less than no booking at all, because a driver will act on it.

Why the list of named channels is short

Every named channel is a parser somebody maintains. A maintained parser is a commitment with a name against it, not a checkbox on a page.

A booking source declares its intake format, and an adapter turns that format into one parsed intake. Adding a channel means writing an adapter, testing it against real messages from that channel, and owning it the next time the channel changes something. That is how Parkos and Solution Park were added, and it is the honest answer to "do you integrate with X". Yes, after that work, done with your channel, and here is roughly what it takes.

The intake pipeline, the adapters and the review queue were built by the engineering team at JADEV, the group ParkAgenda belongs to. It is also why these decisions are written down somewhere rather than remembered.

What this is not

Worth saying plainly, because the alternative is a demo that ends with a question about the connector catalogue.

There is no public or partner API programme. No API keys, no client credentials, no self-service integration: any caller needs an identity in ParkAgenda's own tenant. There are no outbound webhooks either, so nothing is pushed anywhere. And the pull is one way. ParkAgenda reads a source on a cursor and never writes back to it, which means a cancellation you make here does not cancel anything at the reseller.

There is a documented REST API with an OpenAPI description, and it is real. It is what a bespoke connector is built against, by our team, with your supplier.

Five questions worth putting to any vendor

• Which channels are named, and is each one a parser somebody maintains or a logo on a page?
• What happens to a booking the system cannot match? Where does it go, who sees it, how long does it sit there?
• Can I open a booking and see the raw message that produced it?
• What does adding my fourth reseller cost, in time and in money, and who writes it?
• Does anything ever get written back to the reseller?

Questions we get

Can you read our reseller's format without asking them to change anything?

That is the design. The reseller keeps sending what they already send, and an adapter translates it on our side. Asking a channel that serves thousands of car parks to change its template for one of them is not a plan.

How fast does an unmatched booking reach a person?

It appears in the review queue as the message is processed, with the raw email attached. There is no batch window to wait for. What varies is how quickly somebody looks, and that is a rota question rather than a software one.

Does ParkAgenda send anything back to the reseller?

No. Ingestion is one way. There are no outbound webhooks and nothing is written back to a source.

Where to go next

If you are comparing software, take those five questions into the demo and ask to see the review queue on screen. A vendor who has built one will show you a queue with real failures in it, because a pipeline that never fails is a pipeline that guesses.

More on the same problem: what a booking system has to do when you do not own the sales channel, what integrating with a car park actually means and who does the wiring, and the features page for the queue itself.