Muting "Failed to connect … to data" binding warnings during build

Applies to: @uniformdev/canvas-next (Next.js Page Router) ·
@uniformdev/canvas-next-rsc / @uniformdev/next-app-router (Next.js App Router).

Any framework using the Canvas or Route API clients directly.

TL;DR — These warnings mean a dynamic token is bound to a data element (usually an entry field) that some entries don't have a value for. If the field is legitimately optional, downgrade the token's failure log level to Info in the dynamic token editor (Option 1). To turn off SDK response logging entirely in the Page Router SDK, pass silent: true to the data-fetching wrapper (Option 2).

Contents

• Problem

• Why this happens

• Option 1 (recommended): Downgrade the dynamic token to Info level

• Option 2: Mute response logging in the SDK with silent: true

  • Next.js Page Router

  • Next.js App Router

  • SDK-neutral

• Choosing between the options

Problem

During a static build (SSG) or server-side render, the console fills with warnings like this — one per affected component, on every page render:

> BINDING Failed to connect alternatekeywords to data: Dynamic token
  '/entry/fields/alternatekeywords/value' does not exist in Feature Items entries Loop Item.

          The 'alternatekeywords' element of the path did not exist

          Result action: token value removed
          Binding expression: /Feature Items entries Loop Item/entry/fields/alternatekeywords/value
          Occurred on component featureItem at slot path .Base[2].features[15]

On sites with many pages or large loops, these warnings can flood the build output and drown out logs you actually care about.

Why this happens

A parameter on a component uses a dynamic token bound to a data element (for example, an entry field). At render time, some of the connected entries simply don't have a value for that field — common when the field is optional in the content type.

When a binding can't resolve:

1. The configured result action runs. By default, the unresolved token is removed from the output — usually exactly what you want.

2. A binding issue is recorded on the composition API response at the token's configured log level — Warning by default.

3. The SDK that fetched the composition may print the response's warnings and errors to the console. The Next.js Page Router SDK does this by default.

The rendered output is typically fine — the noise is purely informational. There are two ways to quiet it, and they solve slightly different problems.

Option 1 (recommended): Downgrade the dynamic token to Info level

If the field is legitimately optional, a missing value isn't really a warning — declare that on the binding itself. The SDK only prints issues logged at Warning or Error level; Info-level issues are never written to the console, regardless of SDK or framework.

In the Uniform dashboard:

1. Open the component (or pattern) that has the bound parameter — in the example above, the featureItem component's alternatekeywords parameter.

2. Click the dynamic token to open the token editor.

3. Under the "if the connected data element is missing" options, change the log level from Warning to Info.

4. Save and republish.

If you edit binding expressions directly (for example, via the API or CLI), the log level is the fl qualifier on the token — fl=i for Info:

${#jptr:/entry/fields/alternatekeywords/value:fl=i}

Note: Setting a default value on the token does not change the log level. The default is applied, but the issue is still recorded at the configured level. To silence the message, change the log level.

Why this is the recommended fix: it is targeted (only the bindings that are expected to be missing go quiet), it works identically across all SDKs and frameworks, and warnings about bindings that are genuinely broken keep showing up.

Option 2: Mute response logging in the SDK with silent: true

If you'd rather turn off the SDK's response logging entirely, the Page Router SDK's data-fetching wrappers accept a silent option.

Next.js Page Router (@uniformdev/canvas-next)

Route API-based fetching (the default in current starters):

// pages/[[...path]].tsx
import { withUniformGetStaticProps } from '@uniformdev/canvas-next/route';

export const getStaticProps = withUniformGetStaticProps({
  requestOptions: { state: getState() },
  silent: true, // 👈 disables route/composition response logging
});

The same option is available on withUniformGetServerSideProps (for SSR) and on the slug- and project-map-based variants:

// pages/[...slug].tsx (slug-based fetching)
import { withUniformGetStaticProps } from '@uniformdev/canvas-next/slug';

export const getStaticProps = withUniformGetStaticProps({
  param: 'slug',
  silent: true,
});

What silent: true suppresses: the Fetch route … / Matched … lines, the diagnostics timing table, and all composition warnings and errors — including ones that indicate real problems (a data resource that failed to fetch, for instance). It is all-or-nothing; there is currently no per-level or per-category filter.

Next.js App Router (@uniformdev/canvas-next-rsc, @uniformdev/next-app-router)

The App Router SDKs do not print composition binding warnings to the console — there is nothing to mute. If you migrated from the Page Router SDK and the noise disappeared, this is why.

The warnings are still present on the API response if you want to inspect them, for example in a custom data-fetching path:

const response = await retrieveRoute(props);
// response (composition type) carries compositionApiResponse.warnings / .errors
// — log, ignore, or report them however you choose.

SDK-neutral (any framework, using the API clients directly)

The core clients (CanvasClient, RouteClient from @uniformdev/canvas) never log binding issues themselves — the warnings are just data on the response. Whatever your integration prints is under your control:

import { CanvasClient, CANVAS_PUBLISHED_STATE } from '@uniformdev/canvas';

const client = new CanvasClient({
  apiKey: process.env.UNIFORM_API_KEY,
  projectId: process.env.UNIFORM_PROJECT_ID,
});

const response = await client.getCompositionBySlug({
  slug: '/features',
  state: CANVAS_PUBLISHED_STATE,
});

// Binding issues are on the response — decide what deserves the console.
// For example: surface only errors, ignore warnings entirely:
if (response.errors?.length) {
  console.error('Composition data errors', response.errors);
}

Choosing between the options

Use Option 1 when the missing data is expected (optional fields). Use Option 2 when you want quiet builds and are comfortable monitoring composition health another way (for example, in the Uniform dashboard or via your own logging around the response).