Thresholds
A threshold turns a number into a judgement. APIPulse uses three limits per measure to place each supplier in one of four bands, and the worst band across look-to-book, latency and errors becomes the verdict. The built-in presets are illustrative starting points; the right limits come from your supplier agreements and your own history.
How the bands work
Each measure has three ascending limits, a, b and c:
- below a: Excellent
- from a up to b: Good
- from b up to c: Warning
- at or above c: Critical
The supplier's verdict is the worst of its three bands. A supplier with an excellent ratio and a critical error rate is critical. This is deliberate: one failing measure is enough to cost bookings, and averaging would hide it.
The built-in presets
These are the values APIPulse starts with. They are illustrative and not taken from any supplier's agreement.
| Preset | Look-to-book (searches per booking) | Latency (ms) | Error rate (%) |
|---|---|---|---|
| Generic B2B API | 10,000 / 100,000 / 500,000 | 1,500 / 3,000 / 6,000 | 2 / 5 / 10 |
| TravelTech / Flights | 20,000 / 150,000 / 600,000 | 1,500 / 3,000 / 6,000 | 2 / 5 / 10 |
| Hotels / Bedbanks | 10,000 / 80,000 / 400,000 | 1,500 / 3,000 / 6,000 | 2 / 5 / 10 |
Calibrating to your own agreements
Look-to-book
If the agreement states a maximum ratio or a fee above a level, that level is your Critical limit (c). Put Warning (b) well below it, at the point where you would want time to react; half to three quarters of the cap is a common choice. Set Excellent (a) from your own best quarter with that supplier.
Check how the agreement defines a look and over which period it is measured. A monthly cap tolerates a busy week that a weekly cap would not.
Latency
If there is a response-time commitment, use it as the Warning or Critical limit, depending on whether it is a target or a hard limit. Without one, start from your own data: the typical response time of the last quarter is a fair Good limit, and your timeout is the natural Critical limit. Decide whether you enter averages or p95 and keep to it; p95 limits need to be higher. See Latency.
Error rate
Base the limits on technical errors only. Set them from your recent baseline and from what a failed call costs at that step. Booking-step errors deserve tighter limits than search errors, which is a reason to review the booking step separately. See Error rates.
Review them
Thresholds age. Agreements are renegotiated, traffic grows, suppliers change platforms. Revisit them with each contract change and at least twice a year, and keep a note of why each limit was chosen. A limit without a reason is soon ignored.
Worked example
Illustrative numbers. An agreement caps look-to-book at 30,000:1 for the month. The team sets look-to-book limits of 5,000 / 15,000 / 30,000, latency limits of 1,000 / 2,500 / 5,000 ms and error limits of 1 / 3 / 6%.
This month: 600,000 searches, 25 bookings, 1,200 ms average latency, 0.8% errors. L2B is 24,000:1, inside the cap but past the Warning limit, so the verdict is Warning. With the Hotels preset the same numbers would read Good; the calibrated limits catch the approaching cap a month earlier.
Setting them in APIPulse
Open Thresholds under the single check, edit the limits, and save the check with a supplier name. The limits are stored with that supplier's profile and are used again whenever you check or batch-rank that supplier, in this browser.