[Maffooch]

Description

Documents how to list the custom field values on one object through /api/v2/custom_fields/values/. The Pro custom fields page only gave ?finding={id} as an example, so there was no documented way to get the values on an asset, organization, engagement, test or risk acceptance.

The page now has a table of the query parameter for each object type that can hold a custom field value. It also notes that ?asset= and ?organization= work alongside ?product= and ?product_type=, that filters combine, that a non-numeric id is a 400, and that the definitions endpoint filters by entity_type.

This documents a Pro change that adds the asset and organization aliases and the 400. Merge the two together.

Docs only: no code changes.

🤖 Generated with Claude Code

[Maffooch]

Docs review verdict: APPROVE

I checked the changed text in docs/content/asset_modelling/PRO__custom_fields.md (head 9462559) against the Pro implementation of the custom field values and definitions endpoints.

Checked and accurate:

• Values filters: the accepted query parameters are finding, product, product_type, engagement, test and risk_acceptance, plus the aliases asset (same as product) and organization (same as product_type). The table matches this exactly.
• Both endpoints are mounted at /api/v2/custom_fields/values/ and /api/v2/custom_fields/definitions/ with the token, session and basic authentication set, so the path in the example is right.
• Filters combine: each supplied parameter narrows the same queryset in turn, so only rows matching all of them are returned.
• Visibility: the queryset is first restricted to owners the user can view, so values on objects you cannot view are never returned.
• 400 on values: a non-numeric owner id is rejected with a 400 keyed by the parameter name. The check is digits only, so values such as "abc", "1.5", "-1" or "+1" all return a 400, consistent with "not a whole number". An empty value (for example ?asset=) is ignored rather than rejected, which the text does not claim otherwise.
• Pagination: the viewsets set no pagination of their own, and the API default is limit/offset pagination with a next link, so "follow next (or pass limit and offset)" is correct.
• Definitions entity_type: the model values are finding, product, product_type, engagement, test and risk_acceptance. The aliases asset and organization are accepted and map to product and product_type. An unknown value returns a 400. The text lists the same set, and the example URL is valid.
• Removed wording: dropping "Values are owner-scoped and can be filtered to one object" in favor of the new paragraphs loses no information, and the read/edit permission sentence is preserved.

Markdown and hygiene:

• The table syntax is valid (header, separator, six rows) and renders as a normal pipe table.
• Line wrapping is consistent with the surrounding paragraphs (about 110 columns, hard-wrapped).
• No customer names, internal hostnames, internal links, images or private references in the added text.

Nits (optional, none block merge):

• The 400 sentence could mention that an empty parameter value is ignored, if you want it fully precise.
• The entity_type filter only applies when listing definitions, not when fetching a single definition. This is unlikely to matter to readers.