Skip to main content
RapidDev - Software Development Agency
cursor-tutorial

How to Prevent Breaking API Contracts with Cursor

Cursor can generate GraphQL schema changes that break existing clients by removing fields, changing types, or renaming operations without deprecation. By adding .cursor/rules/ with backward compatibility requirements, referencing your existing schema with @file, and prompting with explicit versioning constraints, you can ensure Cursor generates additive-only schema changes that maintain API contracts with existing consumers.

What you'll learn

  • How to create Cursor rules that enforce backward-compatible GraphQL changes
  • How to prompt Cursor for additive-only schema modifications
  • How to use @file to reference existing schemas as constraints
  • How to generate deprecation notices instead of breaking removals
Book a free consultation
4.9Clutch rating
600+Happy partners
17+Countries served
190+Team members
Beginner7 min read10-15 minCursor Free+, GraphQL projectsMarch 2026RapidDev Engineering Team
TL;DR

Cursor can generate GraphQL schema changes that break existing clients by removing fields, changing types, or renaming operations without deprecation. By adding .cursor/rules/ with backward compatibility requirements, referencing your existing schema with @file, and prompting with explicit versioning constraints, you can ensure Cursor generates additive-only schema changes that maintain API contracts with existing consumers.

Preventing breaking API contracts with Cursor

GraphQL APIs promise stability to clients through their schema contract. When Cursor modifies a schema, it can remove fields, change return types, or rename operations without understanding that existing clients depend on the current shape. This tutorial configures Cursor to treat your GraphQL schema as a contract and generate only additive, non-breaking changes.

Prerequisites

  • Cursor installed with a GraphQL project
  • An existing GraphQL schema file
  • Basic understanding of GraphQL schema design
  • Familiarity with Cursor Chat (Cmd+L) and project rules

Step-by-step guide

1

Create a GraphQL backward compatibility rule

Add a project rule that enforces additive-only schema changes. This rule prevents Cursor from removing fields, changing types, or making required arguments optional. It also mandates @deprecated directives instead of removals.

.cursor/rules/graphql-compat.mdc
1---
2description: Enforce backward-compatible GraphQL schema changes
3globs: "*.graphql,*.gql,*.resolver.ts,*.schema.ts"
4alwaysApply: true
5---
6
7# GraphQL API Contract Rules
8- NEVER remove existing fields from a type
9- NEVER change the return type of an existing field
10- NEVER rename existing queries, mutations, or subscriptions
11- NEVER make a previously optional argument required
12- ALWAYS add new fields instead of modifying existing ones
13- ALWAYS use @deprecated(reason: "...") before removing fields
14- New required arguments must have default values
15- New enum values are safe to add
16- Breaking changes require a new API version (v2)
17
18## Safe Changes (ALLOWED):
19- Adding new fields to existing types
20- Adding new queries, mutations, subscriptions
21- Adding new types, enums, unions
22- Adding optional arguments to existing fields
23- Deprecating fields with @deprecated
24
25## Breaking Changes (NEVER without versioning):
26- Removing any field, type, or operation
27- Changing a field's return type
28- Making optional arguments required
29- Removing enum values

Expected result: Cursor generates additive-only GraphQL schema changes and uses @deprecated for field removals.

2

Reference the existing schema when making changes

Always reference your current schema file with @file when asking Cursor to modify the API. This gives Cursor the full picture of existing fields, types, and operations that must not be broken.

Cmd+L prompt
1@graphql-compat.mdc @src/schema/schema.graphql
2
3Add a new 'analytics' section to the User type:
41. Add lastLoginAt: DateTime field
52. Add loginCount: Int field
63. Add a new UserAnalytics type with detailed metrics
74. Add a userAnalytics(userId: ID!): UserAnalytics query
8
9Do NOT modify or remove any existing fields on the User type.
10All changes must be additive only.

Pro tip: Start every GraphQL prompt with 'Do NOT modify or remove any existing fields.' This is the single most effective instruction for preventing breaking changes.

Expected result: Cursor adds new fields and types without touching any existing schema definitions.

3

Generate deprecation notices for fields being phased out

When you need to eventually remove a field, ask Cursor to add a @deprecated directive with a reason and migration path. This gives clients time to update while maintaining backward compatibility during the transition.

Cmd+L prompt
1@graphql-compat.mdc @src/schema/schema.graphql
2
3Deprecate these fields (do NOT remove them):
41. User.fullName -> deprecated in favor of User.displayName
52. Query.getUser -> deprecated in favor of Query.user
63. User.avatarUrl -> deprecated in favor of User.avatar.url
7
8Add @deprecated directives with clear reasons and migration paths.
9Add the new replacement fields/queries alongside the deprecated ones.
10Both old and new must work simultaneously.

Expected result: Cursor adds @deprecated directives to old fields and creates new replacement fields, keeping both functional.

4

Validate schema changes with a compatibility check

Use Cursor Chat to compare your proposed schema changes against the existing schema and identify any breaking changes before they reach production.

Cmd+L prompt
1@graphql-compat.mdc @src/schema/schema.graphql @src/schema/schema-proposed.graphql
2
3Compare the existing schema with the proposed changes.
4Identify any breaking changes:
51. Fields removed from any type
62. Return types changed on existing fields
73. Required arguments added without defaults
84. Enum values removed
95. Types renamed or removed
10
11For each breaking change found, explain the impact on existing
12clients and suggest a backward-compatible alternative.

Expected result: Cursor identifies breaking changes in the proposed schema and suggests backward-compatible alternatives.

5

Generate resolver updates that maintain both old and new fields

When adding replacement fields alongside deprecated ones, both need working resolvers. Ask Cursor to generate resolvers that serve both the old and new schema simultaneously.

Cmd+L prompt
1@graphql-compat.mdc @src/schema/schema.graphql @src/resolvers/user.resolver.ts
2
3Update the User resolver to support both deprecated and new fields:
41. fullName (deprecated) still returns firstName + lastName
52. displayName (new) returns the preferred display name
63. avatarUrl (deprecated) still returns the URL string
74. avatar (new) returns { url, width, height, format }
8
9Both old and new resolvers must work simultaneously.
10Share logic between deprecated and new resolvers to avoid duplication.

Expected result: Cursor generates resolvers that serve both deprecated and new fields with shared logic to avoid duplication.

Complete working example

.cursor/rules/graphql-compat.mdc
1---
2description: Enforce backward-compatible GraphQL schema changes
3globs: "*.graphql,*.gql,*.resolver.ts,*.schema.ts"
4alwaysApply: true
5---
6
7# GraphQL API Contract Rules
8
9## Core Principle:
10The GraphQL schema is a CONTRACT with clients. Every change must be backward-compatible.
11
12## NEVER (Breaking Changes):
13- Remove existing fields from any type
14- Change the return type of an existing field
15- Rename existing queries, mutations, or subscriptions
16- Make previously optional arguments required
17- Remove values from enums
18- Remove types that are used in any operation
19
20## ALWAYS (Safe Changes):
21- ADD new fields to existing types
22- ADD new queries, mutations, subscriptions
23- ADD new types, enums, unions, interfaces
24- ADD optional arguments with default values
25- USE @deprecated(reason: "Use newField instead") before removal
26
27## Deprecation Pattern:
28```graphql
29type User {
30 fullName: String @deprecated(reason: "Use displayName instead")
31 displayName: String
32}
33```
34
35## Versioning:
36- Minor changes: additive fields, new operations
37- Major changes (breaking): require /v2 API version
38- Deprecated fields: minimum 6-month deprecation window

Common mistakes when preventing Breaking API Contracts with Cursor

Why it's a problem: Asking Cursor to 'refactor' a GraphQL schema without specifying backward compatibility

How to avoid: Use 'extend' or 'add to' instead of 'refactor'. Always include 'do not remove or modify existing fields' in the prompt.

Why it's a problem: Not referencing the existing schema when requesting changes

How to avoid: Always reference your schema file with @file so Cursor sees the complete current state before suggesting changes.

Why it's a problem: Removing deprecated fields immediately after adding replacements

How to avoid: Add a rule specifying a minimum deprecation period (e.g., 6 months). Only remove fields after confirming no clients still use them.

Best practices

  • Always reference the current schema with @file before requesting changes
  • Use additive language in prompts: add, extend, augment — not refactor, restructure, replace
  • Add @deprecated with clear reasons and migration paths before removing any field
  • Generate resolvers for both old and new fields to support the transition period
  • Validate proposed schema changes with a compatibility check prompt before implementing
  • Keep a changelog of schema changes committed alongside the schema file
  • Test schema changes against existing GraphQL client queries before deploying

Still stuck?

Copy one of these prompts to get a personalized, step-by-step explanation.

ChatGPT Prompt

I need to add user analytics fields to my GraphQL User type without breaking existing clients. Show me how to add new fields, deprecate old ones with @deprecated directives, and maintain backward compatibility. Include resolver updates.

Cursor Prompt

@graphql-compat.mdc @src/schema/schema.graphql Add order tracking fields to the existing Order type. Add a new OrderTracking type with status history. All changes must be additive only. Do NOT modify or remove any existing fields. Use @deprecated for any fields being replaced.

Frequently asked questions

Can I use GraphQL schema linting to catch breaking changes?

Yes. Tools like graphql-schema-linter and GraphQL Inspector can diff schemas and flag breaking changes in CI. Configure these alongside Cursor rules for defense in depth.

How do I handle required field additions?

New required fields must have default values or be nullable initially. Add the field as optional first, backfill existing data, then make it required in a later release.

What about union and interface changes?

Adding new types to a union is safe. Removing types from a union is breaking. Adding fields to an interface is breaking for implementors. Add these specifics to your rules.

How long should I keep deprecated fields?

Industry standard is 6-12 months. Monitor field usage through GraphQL analytics before removing. Add the minimum period to your rules file.

Does this apply to REST APIs too?

The same principles apply: additive changes only, deprecation before removal, versioning for breaking changes. Adjust the rules for REST-specific patterns like URL versioning.

Can RapidDev help design our API evolution strategy?

Yes. RapidDev designs API versioning strategies, sets up schema validation in CI, and configures Cursor rules to maintain backward compatibility across GraphQL and REST APIs.

RapidDev

Talk to an Expert

Our team has built 600+ apps. Get personalized help with your project.

Book a free consultation

Need help with your project?

Our experts have built 600+ apps and can accelerate your development. Book a free consultation — no strings attached.

Book a free consultation

We put the rapid in RapidDev

Need a dedicated strategic tech and growth partner? Discover what RapidDev can do for your business! Book a call with our team to schedule a free, no-obligation consultation. We'll discuss your project and provide a custom quote at no cost.