Skip to main content

Visible Fields

Two GET endpoints returning attribute names that are appropriate to display. They differ only in how you identify what you are asking about: by asset type and scope, or by a specific asset.

Both apply the filtering described in the overview — a narrower set than everything meta.v1 reports.

api/visibleFields​

GET ~/api/visibleFields?scopeOid=Scope:0&assetTypeToken=Story&assetTypeToken=Defect

Both parameters repeat. Pass assetTypeToken once per asset type, and scopeOid once per scope. This is a plain repeated-key query string, not a comma-separated list.

ParameterRepeatableDescription
scopeOidyesScope OID tokens providing the context for visibility
assetTypeTokenyesAsset types to report on

Response​

An array with one entry per requested asset type. Property names are camelCase, which is worth noting because the server-side model declares them capitalised — the JSON formatter lowercases them on the way out.

[
  {
    "assetType": "Story",
    "fields": ["Estimate", "Name", "Number", "Scope", "Status"]
  },
  {
    "assetType": "Defect",
    "fields": ["Name", "Number", "Priority", "Scope", "Status"]
  }
]

fields is sorted by name and de-duplicated.

Do not mix global and non-global asset types

Some asset types are global — they have no scope context. Requesting a mixture returns 400 with:

Cannot mix global and non-global asset types.

The rule is all-or-nothing:

  • Every requested type is global → the scope context is ignored entirely and a global context is used. scopeOid has no effect.
  • No requested type is global → a multi-scope context is built from the scopeOid values.
  • A mixture → 400.

Split the request in two if you need both.

api/visibleFieldsByAsset​

GET ~/api/visibleFieldsByAsset?oidToken=Story:1234
ParameterDescription
oidTokenOID token of the asset to report on

The server resolves that asset's Scope and uses it as the visibility context, so you do not supply a scope yourself.

Response​

A flat array of attribute names — note this is a different shape from api/visibleFields, which wraps each list in an object with its asset type:

["Estimate", "Name", "Number", "Scope", "Status"]

Custom Fields Are Included​

Both endpoints include custom fields once they are configured for display in the scope. This is the main reason to call them rather than reasoning from meta.v1 alone: a custom field exists in the schema regardless, but whether it should be shown depends on workspace configuration that only these endpoints apply.

If you want only the custom fields, use api/customFields — but note it is a POST.