bcquality/microsoft/knowledge/style/api-page-version-format.md
Jesper Schulz-Wedde b6da405376 Improve partner onboarding and documentation navigation
Lead with a complete plugin quick start and add task-oriented usage, troubleshooting, customization, and contribution guides. Preserve the broader plugin framing, correct conflicting contract guidance, support Agents folder reviews, and align repository validation. Convert existing sample references to clickable links without changing knowledge rules.

Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
2026-09-09 17:25:29 +02:00

1.4 KiB

bc-version domain keywords technologies countries application-area
all
style
api-page
apiversion
version
format
beta
al
w1
all

APIVersion must follow the pattern vX.Y (or beta)

Description

The APIVersion property on an API page is part of the public URL path: /api/<publisher>/<group>/<version>/<entitySetName>. The platform accepts only two value shapes for it: a vMAJOR.MINOR string such as 'v1.0', 'v2.0', or 'v2.1', or the literal string 'beta' for pre-release endpoints. Anything else — 'v2', '2.0', '1', 'v2.0.0' — is rejected. The major-minor pair lets consumers detect compatibility through URL inspection alone; the explicit 'beta' channel signals "this contract may break without notice."

Best Practice

Start a new public endpoint at 'v1.0'. Bump the minor when adding fields or non-breaking changes; bump the major when changing field types, removing fields, or any breaking change. Use 'beta' for endpoints that are still iterating and SHOULD NOT be consumed by external integrations.

See sample: api-page-version-format.good.al.

Anti Pattern

APIVersion = 'v2' (missing minor), APIVersion = '2.0' (missing v prefix), APIVersion = 'v2.0.0' (extra segment). All three either fail to compile or produce a URL that consumers cannot reach.

See sample: api-page-version-format.bad.al.