The first buyer integration anyone builds treats the HTTP status as the answer. Two hundred means they took it, anything else means they did not, and the waterfall moves on. It works in testing, it works for a week, and then you notice your sold count is roughly double what the buyer is paying for.
The reason is simple once you see it. A buyer's endpoint returning 200 OK means their server successfully processed your request. It says nothing about whether they wanted the lead. Most serious lead buyers answer like this:
{ "status": "rejected", "reason": "duplicate_in_30_days", "price": 0 }That is a healthy response to a well-formed request. It is also a decline, and if your system counts it as a sale you have just stopped offering that lead to the four buyers below who might have wanted it.
What an accept rule has to read
Deciding whether a lead was taken means looking at three things, in order.
The status code. Still the first gate. A 500 is not a decline, it is a failure — you may want to treat those differently, because a buyer having a bad ten minutes is not the same as a buyer saying no.
The body. This is where the real answer lives. You need to reach into the response and test a specific value: status equals accepted, or result.code is in a list of codes that mean yes, or payout is greater than zero. That last one is worth calling out — for a lot of buyers, the price is the verdict. A zero bid is a decline no matter what the status field says.
The price. Once you have decided it was a sale, you want the number. Capturing it at the moment of acceptance means your reporting is built from what buyers actually said rather than from a rate card that drifted three months ago.
The parsing problem nobody warns you about
You will be told the response is JSON. Sometimes it is XML. Sometimes it is form-encoded. Occasionally it is JSON with a Content-Type of text/html, because someone configured a web server in 2014 and nobody has touched it since.
Trusting the Content-Type header is therefore a mistake. The pragmatic approach is to try each format in turn — JSON, then XML, then form-encoded — and use whichever parses. It feels sloppy. It is considerably less sloppy than a buyer integration that silently stops working because they upgraded a load balancer.
The same goes for key matching. A buyer who returns Status this month and status next month has not told you they changed anything, and probably does not consider it a change. Case-insensitive lookups cost nothing and save an incident.
Failing in the expensive direction
There are two ways to get an accept rule wrong, and they are not symmetrical.
Too strict and you decline sales you actually made. The lead falls through to the next buyer, who also takes it, and now you have sold one lead twice. Your buyer notices before you do.
Too generous and you mark leads sold that nobody bought. This is the one that hurts, because nothing alerts you. Your dashboard looks great. Your revenue does not match it. And every lead marked sold in error is a lead that was never offered to the buyers underneath — so you are not just miscounting, you are losing money on leads you already paid to acquire.
If you have to be wrong, be wrong in the strict direction. A double-sold lead is an embarrassing phone call. A month of phantom sales is a month of media spend allocated on fiction.
Test it against a real response
The single most useful thing you can do when adding a buyer is to take a real response they gave you — an acceptance and a decline, ideally — and run your rule against both before a live lead ever touches it.
This is not the same as testing the endpoint. The endpoint works; that is why it returned 200. What you are testing is your interpretation of what it said. Those are different failures and they surface at different times, which is exactly why they should be checked separately.
Where this leaves the waterfall
The whole point of an ordered list of buyers is that a decline is a normal, expected, frequent event. Acceptance rates of 20 to 40 percent are ordinary. A waterfall exists because most buyers say no to most leads.
Which means the accept rule is not a detail at the edge of your buyer configuration. It is the thing that decides whether the waterfall works at all. Get it wrong and you either stop at the first buyer every time, or you walk past everyone who would have bought.
Read the body. Test the price. Assume nothing from the status line.