Skip to main content

Can Be Important

Given a batch of attribute-definition tokens, reports which of them can be marked important.

POST ~/api/canbeimportant
Content-Type: application/json

["Story.Name", "Story.Estimate", "Story.Description"]

The request body is a bare JSON array of strings, not an object wrapping one.

Response​

An object keyed by attribute-definition token:

{
  "Story.Name": true,
  "Story.Estimate": true,
  "Story.Description": false
}
Unknown tokens are dropped silently — check the key count

A token the metadata model does not recognise is omitted from the response rather than reported. There is no error, no null, and no indication that anything was ignored — the response simply has fewer keys than the request had entries.

A typo is therefore indistinguishable from a legitimate false unless you look for it. The only reliable check is to compare the number of keys returned against the number of tokens sent, or to look up each token you asked about rather than iterating the response.

Posting ["Story.Name", "Story.Estimate", "Story.NotARealAttribute"] returns exactly two keys, with no mention of the third.

Authentication​

This endpoint carries no authorization attribute. Unlike its neighbours in field visibility, the controller declares neither [AuthorizeApi] nor any equivalent, and a live 26.2 instance answers 200 to an unauthenticated request.

Treat that as observed behaviour on a default configuration rather than as a guarantee. What a deployment actually exposes can be changed at layers the application source does not describe — a reverse proxy or a gateway may authenticate ahead of it. If it matters to your integration, verify against the instance you are targeting rather than relying on this page.

What it returns is metadata about attribute definitions, not customer data.