Skip to main content

Beta endpoints and temporary access restrictions

Beta endpoints let selected integrations try a capability while it is being refined. Look for a Beta badge on the endpoint and in the API catalogue. You can filter the reference to show beta endpoints when they are available.

The portal recognises the OpenAPI x-beta: true marker automatically.

The currently imported reference does not yet contain beta-marked operations. This guide describes how they will be presented when their specification is published; it does not announce that a particular new endpoint is available.

Plan for change​

Arrange beta participation with LMG before using a beta endpoint in a production workflow. Confirm the environment, permitted adviser context, enabled feature and the expected process for changes. During beta, request fields, validation or behaviour may be refined; isolate that dependency so you can update it deliberately.

423 Locked is temporary during beta​

An otherwise authorised request can receive HTTP 423 Locked, with JSON:API error code feature_not_enabled, when:

  • The beta feature is not enabled for the resolved user.
  • A valid user cannot be resolved for the feature check.

This is a temporary beta rollout restriction, not a permanent lock or an ongoing requirement for the endpoint's general availability. It does not indicate that another request holds a database lock. The final generally available contract should be checked when the endpoint leaves beta; do not invent a graduation date or assume the flag is removed before the published contract changes.

An illustrative error envelope is:

{
  "errors": [
    {
      "status": "423",
      "code": "feature_not_enabled",
      "title": "Feature not enabled",
      "detail": "The beta feature must be enabled for a valid resolved user."
    }
  ]
}

The status and code are the behaviour to handle; descriptive wording may vary.

What to do​

  1. Verify the request uses the correct environment and a valid token.
  2. Supply the permitted adviser context, including UserId where applicable.
  3. Confirm with LMG that beta access is enabled for that resolved user.
  4. Retry after the context or enablement has changed.

Do not treat 423 like rate limiting or repeatedly retry it. A disabled beta gate prevents the action from executing. However, a timeout during a different request still needs normal write reconciliation.

Beta access does not replace permissions​

OAuth, scope and resource-access checks still apply. Normal authorisation runs before the feature gate, so a missing permission can still produce 401 or 403. Enabling a beta feature does not grant broader access to records.

How the notice appears​

The following is an example of the notice automatically shown on a beta operation that documents 423:

Beta · access by arrangement

This endpoint is in beta. Its behaviour and contract may change as it is refined. Confirm availability with LMG before depending on it in a production integration.

Temporary beta response: 423 Locked. A response with code feature_not_enabled means beta access is not enabled for the resolved user, or a valid user could not be resolved. This is a temporary restriction during the endpoint’s beta period, not an ongoing requirement for its general availability.

Normal OAuth, scope and resource-access checks still apply. Check the adviser context and arrange beta enablement before retrying; repeated retries will not unlock access. Read the beta endpoint guidance →