Which Federation v1 directives are supported?

All Federation v1 directives are fully supported: @key (including composite keys), @extends, @external, @provides, @requires, and @tag.

Are composite @key fields supported?

Yes. @key with composite key fields is fully supported for complex entity resolution scenarios.

Is @interfaceObject supported?

Yes. @interfaceObject is fully supported, allowing a subgraph to contribute fields to every type implementing an entity interface defined in another subgraph.

Can I mix Federation v1 and v2 subgraphs in the same graph?

Yes. Cosmo's composition engine handles mixed-version subgraphs. You do not need to standardize all subgraphs to the same Federation version before migrating. Standard composition rules still apply — if a v2 subgraph shares fields with a v1 subgraph, those fields must be marked @shareable or composition will fail. See understanding Federation versions (/blog/understanding-federation-versions) for background on the differences.

Are authorization directives supported?

Yes. Both @authenticated and @requiresScopes are fully supported. Field-level authorization logic continues working after migration.

Federation v1 and v2 Compatibility | WunderGraph Cosmo

Q: Which Federation v2 directives are supported?

Cosmo supports all major Federation v2 directives through version 2.5: @shareable, @inaccessible, @override, @interfaceObject, @authenticated, @requiresScopes, and @composeDirective. @link is ignored and removed during composition — schemas using it compose correctly.

The problem

Schema compatibility uncertainty stalls migration

Teams cannot commit to a migration that might require rewriting schemas. Incomplete directive support is a blocker before a single line of config changes.

Incomplete directive support means schema rewrites

Teams cannot commit to migration if there is any chance that unsupported directives will force schema changes across dozens of subgraphs. The audit work alone can take weeks.

Version uncertainty blocks migration planning

Organizations running Federation v1 and v2 subgraphs in the same graph need assurance that both versions are handled correctly and that they do not need to standardize before migrating.

Authorization directives are business-critical

Teams using @authenticated and @requiresScopes for field-level access control cannot accept a platform that does not support them. Loss of authorization logic is not an option.

Our solution

Complete Federation compatibility, built into the composition engine

Cosmo implements the Federation specification from v1 through v2.5. All standard directives are supported. Existing schemas compose and execute without modification.

How compatibility works

Cosmo's composition engine processes subgraph schemas and applies Federation directives per the specification.
All Federation v1 directives are fully supported: @key (including composite keys), @extends, @external, @provides, @requires, and @tag.
Federation v2 directives through version 2.5 are supported: @shareable, @inaccessible, @override, @interfaceObject, @authenticated, @requiresScopes, and @composeDirective. (@link is ignored and removed during composition — schemas using it work without changes. To use @composeDirective to propagate a custom directive into the supergraph, that directive must first be imported via @link.)
Mixed-version subgraphs compose correctly. Standard Federation composition rules still apply — v2 subgraphs sharing fields with v1 subgraphs must declare `@shareable` or composition will fail.
The router generates optimized query plans that respect entity resolution, key fields, and cross-subgraph references.
Existing schemas migrate without modification in most cases. The exception: shared fields between v1 and v2 subgraphs must be marked @shareable.

The schema you have today is the schema you migrate.

Federation Compatibility

Before & After

Before Cosmo	With Cosmo
Uncertainty about which directives are supported	Clear compatibility covering v1 through v2.5
Risk of schema rewrites before migration	Existing schemas work without modification
Need to standardize all subgraphs to one Federation version	Mixed v1 and v2 subgraphs compose correctly
Authorization directives may not work on new platform	@authenticated and @requiresScopes fully supported

Directive coverage

v1 through v2.5

Federation v1: @key (composite included), @extends, @external, @provides, @requires, @tag
Federation v2.0–v2.5: @shareable, @inaccessible, @override, @interfaceObject, @authenticated, @requiresScopes, @composeDirective

How Federation compatibility works

01

All v1 and v2 directives.

Compose

Cosmo's composition engine ingests subgraph schemas from all services. It processes Federation directives according to the specification and builds a unified supergraph schema.

02

Spec-compliant validation.

Validate

Composition validates directive usage and cross-subgraph references. Entity keys, @requires dependencies, and @provides declarations are all checked against the Federation rules.

03

Optimized query planning.

Plan

The router generates query plans that respect entity resolution, key fields, and cross-subgraph references. Authorization directives (@authenticated, @requiresScopes) are enforced at both the field and type level.

04

Spec-compatible execution.

Execute

Queries execute against subgraphs in a way that is compatible with the Federation specification. Composite keys, interface objects, and authorization logic all behave as defined.

What's included

Full Federation support, no extras required

Available on Free, Pro, and Enterprise.

Complete Federation v1 support

All v1 directives fully supported: @key with composite keys, @extends, @external, @provides, @requires, and @tag. Federation v1 schemas migrate without changes.

Federation v2 through v2.5

@shareable, @inaccessible, @override, @interfaceObject, @authenticated, @requiresScopes, and @composeDirective are all supported. @link is ignored and removed during composition. Authorization logic continues working after migration.

Schema changes rarely required

Existing schemas migrate without modification in most cases. The exception: shared fields between v1 and v2 subgraphs must be marked @shareable.

Mixed-version subgraphs

The composition engine handles subgraphs using different Federation versions in the same graph. Standard composition rules still apply — no full standardization required before migrating.

Check your Federation compatibility

Review the directives index and start your migration. Your schemas work as-is.

Start Free Read the Docs

Your existing Federation schemas work in Cosmo unchanged