Four times we said the seat could not do it
Four capability claims we published as absences after checking one API endpoint. Placement excludes, dayparting, pacing, and schema were all present on a different surface.
Published 2026-09-09 · Search job: checking one API endpoint
Checking one API endpoint is how we spent months claiming this seat could not do work it was already entitled to do.
Each claim was a confident sentence. Each sentence was derived from a real 404, a real empty list, or a real 400. The mistake was treating that one surface as the whole catalog. The capability map now records four of those sentences so we do not invent a fifth.
Placement and site excludes
We said placement and site exclusions needed Beeswax app_site lists plus a child-seat custom_list the compiler could not emit. That sentence gated Supply Audit apply. It was wrong.
GET /rest/v2/ref/targeting-keys?module=app_site returns twelve keys. placement and site are direct keys: related_field: "key", comparator equals, usage tips <exchange_handle>/<placement_id> and <exchange_handle>/<site_id>. No list object. Domain and app-bundle still need seat-level reference lists. Placement and site never did.
The cost was 59 percent of the waste the first real Supply Audit run found: $47.71 at placement grain and $34.21 at site grain, $81.92 of $138.53. The product could act on $7.79 at exchange grain. The rest sat behind a sentence that sounded like a seat limit.
Dayparting
We said dayparting was unavailable because user_time_of_week was absent from this child seat's targeting-key catalog. The first half is true. /rest/v2/ref/targeting-keys returns 50 keys across app_site, content, environment, exchange, geo, and platform. There is no clock on that list.
Bid modifiers draw on a separate, wider vocabulary. OPTIONS /rest/v2/bid-modifiers returns 66 targeting_key choices, including both time_of_week and user_time_of_week. We treated the targeting catalog as the capability catalog. That cost three months.
Pacing entitlement
We said the seat was not entitled to pace. Setting pacing to daily on strategy CPM returns 400 with "Bidding strategy CPM is not enabled for pacing. Please reach out to your account team." CPC returns the same sentence. The error is true and narrow. The trailing reach-out is boilerplate.
GET /rest/v2/ref/bidding-strategies shows every strategy carries a paced boolean. This seat has CPM id 1 with paced=false and CPM_PACED id 3 with paced=true. We built a product-side pacer that shrinks lifetime budget into slices. That work took four months. The missing string was one catalog row.
Readable schema
We said there was no readable schema surface because /rest/v2/<object>/fields 404s everywhere. That dead end produced guessed macros and a guessed pacing enum.
The authoritative read is DRF OPTIONS. OPTIONS /rest/v2/bid-modifiers returns actions.POST with full field metadata, including the 66-key choice list. The 404 was real. The conclusion that schema does not exist was not.
The rule we keep
Never claim a capability is absent from one endpoint. A 404, an empty module, or a strategy-specific 400 is evidence about that surface. It is not a seat verdict.
The same shape of error made CTR look like a quality score: one easy number, one missing check, a confident story. The next time a sentence says "this seat cannot," the follow-up is which other list we have not read.