OPTIONS, not /fields
Beeswax /rest/v2 object /fields 404s everywhere. DRF OPTIONS on the same object returns actions.POST with the real field metadata, including the 66 bid-modifier targeting keys.
Published 2026-09-09 · Search job: how to read a REST schema
To read a REST schema on this Beeswax seat, call OPTIONS on the object. Do not call /fields.
/rest/v2/<object>/fields 404s everywhere we have tried it. That 404 is stable. It is also the wrong question. Django REST Framework exposes write schema on OPTIONS, under actions.POST, with field types, required flags, and choice lists. Once we started reading that document, three "the seat cannot do this" sentences collapsed.
What OPTIONS actually returns
OPTIONS /rest/v2/bid-modifiers is the example we keep. The response includes actions.POST. Inside that block, terms[].targeting_key is a choice of 66 keys. The list includes time_of_week, user_time_of_week, segment, user_id, ad_size, delivery, feed, and ip_address. None of those eight appear in the 50-key targeting catalog returned by /rest/v2/ref/targeting-keys.
terms[].comparator is exactly three values: equals, in_range, and boolean_expression. That is not inferred from a docs page. It is the enum on the write schema. A daypart written against the wrong comparator fails at create time with a field error instead of silently compiling into a three-minute window.
The same OPTIONS pattern is how we should have read line-item bidding before we guessed a pacing enum. /rest/v2/<object>/fields had already trained us to treat schema as missing. Guessed macros and a guessed pacing vocabulary came from that dead end.
Why the 404 felt like a verdict
A 404 is a satisfying kind of evidence. It looks like the server answering "this does not exist." On this API it answers "this URL is not the schema surface." We had already learned, on placement excludes and on dayparting, that a missing key on one list is not a missing capability. We still used /fields as the schema list.
Try OPTIONS before probing with deliberately invalid POSTs. Invalid POSTs are useful after you know the field names. They are expensive as a discovery tool because a rejected body can be read as an entitlement failure. That is how "Bidding strategy CPM is not enabled for pacing" lasted four months. See The sentence that cost four months.
What we will not claim from OPTIONS alone
OPTIONS tells you what the API will accept on a write. It does not tell you what this child seat is entitled to serve, what a live campaign is currently using, or what a report will return. Entitlement still needs a verified write or a catalog row. Delivery still needs a report. Schema is the first of those checks, not the last.
The four capability mistakes in Four times we said the seat could not do it share one method: we stopped at the first empty or failing surface. /fields was the schema version of that method. OPTIONS is the correction.
If you are integrating against this seat, treat DRF OPTIONS as the authoritative field document. Treat /fields as a known 404. Treat a single-endpoint absence as a prompt to open the next list, not as a product decision.