marketing-guidelines

List Requirements

The library, filterable, sortable, capped, and — when asked — ranked by its own record.

collateral_type and marketing_team_id match a requirement whose scope is unset too, because an unset scope means "applies to everything" — filtering it out would hide the requirements that most certainly do apply. preset_id does not; see below. file_id names the standards documents to read from — strict membership for the same reason preset_id is, and narrower: it answers "which of this document's rules are misbehaving", which is how a librarian who knows the standard they are tuning reaches its rules without paging through the library.

order is a parameter here rather than a route of its own. Ranking a library by how often reviewers dismiss what a rule produced is the same selection as this list, ordered differently, and the tuning surfaces need it with every filter above still applying. A parallel route had five things silently wrong for the same rows: max_requirements_per_state_change absent so the bulk cap read zero against a server that refuses at fifty, three of the five filters dropped while their chips stayed lit, a thinner row that blanked seven fields RequirementCard renders, truncation copy telling the reader to narrow filters when narrowing is not the remedy, and two query keys keepPreviousData cannot span. One route keeps all five right by construction.

With order set, each row carries a signal block and rows with no checks in the window are absent — a requirement nothing has been judged against has no track record to rank. With it unset the query, the plan and the row are exactly what they were before: the aggregates are not joined, so the ordinary library list pays nothing for this.

The ranking is applied here rather than in the browser because the response is one capped page of whatever matched, not a window onto an ordered list — so a client re-ordering what it was sent would answer "which rules produce the most false positives" with the worst of an arbitrary page, silently, on exactly the libraries where the question is worth asking.

get/marketing/guidelines/requirements

Query parameters

stateGuidelineRequirementState[] nullable
collateral_type'Agent Call Flow' | 'Audio' | 'Billboard' | 'Communications' | 'Conversation Design' | 'Email' | 'Help Center Article' | 'In-App' | 'Mailer' | 'Organic Social' | 'Paid Advertising' | 'Paid Search' | 'Paid Social' | 'Press Release' | 'Procedure/Decision Tree' | 'Support Agent Training' | 'TV' | 'Web' | 'Wiki' | 'Other'
marketing_team_idstring uuid nullable
preset_idstring[] nullable
file_idstring[] nullable
searchstring nullable
order'false_positive_rate' | 'dismissal_rate' | 'dismissal_volume' | 'fire_rate' | 'fire_volume'

What a ranking of a company's requirements is ranked by.

Five orders because the two surfaces ask different questions and each wants a rate and a volume. A rate finds the rule that is usually wrong; a volume finds the rule that is wrong most often. Neither subsumes the other, and offering only one is how a screen ends up either dominated by rules with three data points or blind to a rule that is wrong 40% of the time on hundreds of assets.

FIRE_RATE applies MIN_CHECKED_FOR_RATE; the two verdict rates are held down by FALSE_POSITIVE_PRIOR_REVIEWS instead, so a genuinely bad two-of-two stays visible without topping the list. The two volumes need neither: a count is already its own evidence.

direction'asc' | 'desc'

Which way a sortable list is sorted.

Here rather than beside any one feature because a direction is not a property of what is being sorted. backend/api/vendors.py, reviews.py and vendor_services.py each spell it as Query("asc", pattern="^(asc|desc)$"); the wire values match, so those can adopt this without a client change, and nothing new should add a fourth spelling (naming-semantics N-1).

window_daysinteger
min_checkedinteger

Response

Successful Response

truncatedboolean required
signal_floorinteger nullable
signal_window_daysinteger nullable
max_requirements_per_state_changeinteger required

Changes

No recorded changes to this endpoint across all 1 revision of this API.