Error rates
An error rate is failed calls divided by all calls of the same type, for one supplier and one period. The single most useful habit is to split it in two: technical errors, where the connection or the supplier's system failed, and business errors, where the system worked but the answer was no. They have different causes, different owners and different fixes.
Technical errors
The request did not get a valid answer.
- Timeouts on your side
- Server errors (HTTP 5xx), connection resets, TLS failures
- Responses that cannot be parsed or break the agreed schema
- Authentication and rate-limit rejections
These measure reliability. A rising technical error rate is a conversation with the supplier's technical team, or a look at your own connector if the failures follow a deployment.
Business errors
The system answered correctly, but the answer prevents the sale.
- Price changed between search and booking
- Rate or room no longer available at pre-book or book
- Booking rejected by a rule: stay restrictions, occupancy, nationality, payment
- Invalid request: a field your platform sent wrongly
These measure the quality of inventory, pricing and mapping, and sometimes the quality of your own requests. An empty search result is usually not an error at all; count it separately as an availability rate.
Invalid-request errors deserve their own line. They look like supplier problems in a dashboard, but the fix is in your code.
Choose the denominator carefully
Divide by the calls of the same step: search errors by searches, booking errors by booking attempts. Mixing steps hides the failures that matter most. A 0.5% failure rate on booking calls is far more expensive than 0.5% on searches, because each failed booking is a customer who already decided to buy.
Count each logical request once in the error rate, by its final outcome. Keep the failed attempts behind it in a separate retry count: if your connector retries a failed search and the retry succeeds, the request counts as a success, but the retry statistics should still show the failure. Otherwise retries quietly hide an unreliable supplier.
Errors at the booking step
A timeout or connection failure during booking does not mean the booking failed. The supplier may have confirmed it and the response was lost. Treat the outcome as unknown, check the booking status with the supplier, and reconcile before trying again. Retrying a booking blindly is how duplicate reservations happen.
For the same reason, report the booking step with three outcomes rather than two: confirmed, failed and unknown. The unknown count should be small, and every one of them should be resolved.
What a useful report contains
Per supplier and step, for one period:
- Technical error rate, with the main error codes
- Business error rate, split into price change, availability and rule rejections
- Invalid-request rate, owned by your own team
- For booking: confirmed, failed and unknown counts
Read the rates next to volume. A 10% error rate on 30 calls is noise; on 300,000 calls it is an incident.
Worked example
Illustrative numbers. A supplier receives 50,000 searches, confirms 40 bookings and answers in 700 ms on average, but 6% of calls fail with technical errors.
L2B is 1,250:1 and latency is Fast, yet against the Generic preset the error rate is Elevated, so the verdict is Warning. The supplier is quick and converts well when it works, which points the review at reliability rather than at traffic or pricing.
How APIPulse scores it
APIPulse takes one error-rate figure, as a percentage, and rates it Low, Acceptable, Elevated or High against the selected thresholds. Enter the technical error rate there; business errors are better reviewed separately because their causes and owners differ. The error rate is optional: if you leave it empty, it is left out of the verdict and the report says so.