Key Takeaways (TL;DR)
- What is Salesforce GraphQL API? Salesforce GraphQL API is a single-endpoint API for querying UI API-supported Salesforce data, metadata, layouts, and related records in one structured request.
- Key Benefit: It can reduce round trips compared with multiple REST calls, especially for Lightning Web Components, portal experiences, and apps that need related Salesforce data at once.
- 2026 Admin Priority: Audit integrations now because SOAP
login()is no longer available in API v65.0 and is scheduled to be fully retired for older SOAP versions in Summer ’27. - GraphQL vs REST vs SOAP: Use GraphQL for UI-shaped, relationship-heavy reads; REST for straightforward CRUD and broad resource coverage; SOAP only where legacy tooling still requires it while you plan migration.
- Best For: Salesforce admins, architects, integration owners, and business systems teams modernizing API usage before authentication and API-version changes create disruption.
- Bottom Line: GraphQL is not a universal replacement for REST or Bulk API, but it should be on every 2026 Salesforce API migration checklist.
Meta Description: Salesforce GraphQL API examples for admins: when to use GraphQL vs REST or SOAP, key 2026 changes, migration checklist, and query patterns.
What Changed: GraphQL Is Becoming Part of the Salesforce Admin Toolkit
Salesforce GraphQL API is no longer only a developer curiosity. In 2026, it matters to admins because the API decisions behind Lightning Web Components, portals, mobile experiences, and middleware integrations increasingly affect performance, permissions, security reviews, and long-term maintainability.
The practical change is this: Salesforce teams have more API choices than ever, but old integration patterns are also aging out. Salesforce’s Winter ’26 developer guidance states that SOAP login() is no longer available in API version 65.0 and that SOAP login() in API versions 31.0 through 64.0 is scheduled to be retired when Summer ’27 is released. That does not mean “replace every SOAP integration with GraphQL.” It means admins should inventory API usage, confirm authentication patterns, and decide where GraphQL, REST, Bulk API, or another Salesforce API is the right migration target.
GraphQL is especially useful when the front end or integration needs a specific shape of Salesforce data: an account plus related contacts, a case list plus selected fields, object metadata for dynamic UI, or optional fields that should not break a query when a user lacks field-level access.
Who Is Affected?
You should pay attention if your organization has any of the following:
- Custom Lightning Web Components that make multiple UI API, Apex, or REST calls to render one screen.
- Experience Cloud, partner portal, customer portal, or embedded app experiences that need Salesforce record data quickly.
- Middleware or custom apps that still use SOAP
login()or older API versions. - Integrations built years ago with hard-coded authentication assumptions.
- Admin-owned automations that depend on developer-built API services but lack clear documentation.
- Business teams complaining that custom pages, related lists, or record summaries load slowly.
Admins do not need to write every GraphQL query themselves. But they do need to know enough to ask the right questions, review integration risk, and validate that new API work aligns with Salesforce’s 2026 direction.
What Admins Need to Know About Salesforce GraphQL API
Salesforce GraphQL API lets a client send a structured query to one endpoint and receive exactly the requested data shape. Salesforce’s documentation describes it as a way to interact with the Salesforce Platform through GraphQL, a standard query language and runtime for APIs. Unlike typical REST patterns where an app might call one endpoint for accounts, another for contacts, another for metadata, and another for layouts, GraphQL can retrieve multiple pieces of UI API-supported data in one request.
A few Salesforce-specific points matter:
- GraphQL uses the UI API family. The
uiapifield is the top-level entry point for record queries, aggregate queries, object metadata, related list metadata, current user data, and layouts. - It respects Salesforce permissions. Object-level and field-level permissions control what the context user can access.
- It is versioned. Salesforce includes the API version in the GraphQL endpoint because the schema depends on API version capabilities.
- It has limits. GraphQL follows SOQL-like limitations, supports only UI API-supported objects, and has query/subquery constraints.
- It is not just read-only anymore. Mutations for create, update, and delete are generally available in API v66.0 and later, after being beta in v59.0 through v65.0.
Salesforce GraphQL vs REST vs SOAP: Which Should You Use?
The most common admin question is not “What is GraphQL syntax?” It is “Should we use GraphQL, REST, or SOAP for this Salesforce project?”
| API Option | Best Use Cases | Admin Decision Rule | Watchouts |
|---|---|---|---|
| GraphQL API | UI-shaped reads, related record data, dynamic Lightning Web Components, fewer round trips, metadata-driven screens | Use when one screen or app needs a precise data shape from multiple related Salesforce resources | Only UI API-supported objects are available; queries still follow limits; teams need GraphQL knowledge |
| REST API | Standard record CRUD, simple queries, integration services, broad Salesforce resource access | Use when the integration maps cleanly to known Salesforce resources or SOQL queries | Multiple REST calls may be needed for complex screens; avoid over-fetching data |
| SOAP API | Legacy enterprise integrations, older vendor connectors, WSDL-based tooling | Keep only where required, and plan authentication/API-version modernization | SOAP login() retirement creates migration risk; newer projects should generally avoid SOAP login patterns |
| Bulk API 2.0 | High-volume extracts, loads, and data migration jobs | Use for large data movement, not interactive UI screens | Not designed for real-time UI experiences |
| Metadata/Tooling APIs | Deployments, metadata inspection, developer tooling | Use for admin/dev lifecycle tasks, not normal business-record reads | Different permissions and operational risk profile |
Short answer: GraphQL is strongest when the consumer needs a custom data shape, especially for UI or near-UI use cases. REST remains the default for straightforward integration work. SOAP should be treated as legacy unless a vendor or enterprise system specifically requires it.
How Does the SOAP API Login Retirement Fit In?
Salesforce’s SOAP login() change is an authentication and API modernization issue. GraphQL is one possible modernization path for certain data access patterns, but it is not a one-for-one SOAP replacement.
Here is the clean way to think about it:
- If the old SOAP integration mainly authenticates with
login()and then reads a few records: move authentication to an external client app/OAuth pattern, then evaluate REST or GraphQL for data access. - If the old SOAP integration performs bulk data operations: evaluate Bulk API 2.0, REST Composite, or a middleware-managed pattern.
- If the old SOAP integration feeds a custom UI or portal: GraphQL may reduce round trips and simplify the front-end data contract.
- If a vendor owns the SOAP connector: ask for their Summer ’27 readiness plan, supported authentication method, and target API versions.
Admins should avoid the trap of turning the SOAP retirement into a single technical ticket. It is a portfolio review: authentication, API versions, connected apps, integrations, vendors, and business processes all need to be mapped.
Urgency Timeline for Admins
| Timeline | What to Do | Why It Matters |
|---|---|---|
| Now through Q2 2026 | Inventory all Salesforce integrations and identify API type, API version, auth method, owner, and vendor | You cannot migrate what you cannot see |
| Q3 2026 | Flag SOAP login() usage, API versions below v65.0, hard-coded login endpoints, and unmanaged connected apps |
These are the highest-risk modernization items |
| Q4 2026 | Prioritize replacements: OAuth/external client app first, then data API choice such as REST, GraphQL, Bulk, or middleware | Authentication and data access should be designed together |
| Q1-Q2 2027 | Test migration paths in sandbox, update monitoring, and validate regression scenarios | Avoid last-minute production surprises |
| Before Summer ’27 | Complete remediation for SOAP login() dependencies and document the new support model |
Salesforce has signaled disruption for apps that continue using retired SOAP login patterns |
Step-by-Step Admin Action Checklist
Use this checklist before approving new Salesforce API work in 2026.
- Create an integration inventory. Include owner, vendor, business process, API type, auth method, API version, connected app, user/account, and last confirmed test date.
- Find SOAP
login()usage. Ask developers and vendors directly: “Does this integration call SOAPlogin()? Which API version?” - Confirm authentication modernization. Production apps should use an OAuth flow through an external client app or connected app pattern that fits the use case.
- Classify the data pattern. Is the integration reading a UI-shaped set of related records, doing simple CRUD, moving high-volume data, or managing metadata?
- Choose the API based on the pattern. GraphQL for UI-shaped related data; REST for straightforward resources; Bulk for large data movement; Metadata/Tooling for lifecycle operations.
- Validate user permissions. GraphQL respects object-level and field-level security, so test with realistic user profiles, not only admin users.
- Review limits before launch. GraphQL queries can contain up to 10 subqueries, each subquery counts as one request for rate limiting, and each subquery can return up to 2,000 records.
- Require sample queries in documentation. Admins should be able to see what objects and fields are being accessed.
- Add monitoring. Track API usage, error rates, and Salesforce system overview metrics after launch.
- Document support ownership. Every integration should have a named business owner and technical owner.
Key Salesforce GraphQL API Query Examples
The following examples are written for admins and architects reviewing proposed API work. They are not a substitute for developer testing, but they show the patterns you should recognize.
Example 1: Query Account Names and IDs
Use this simple query to understand the basic shape. Salesforce returns records through a connection with edges and node.
query accounts {
uiapi {
query {
Account(first: 10) {
edges {
node {
Id
Name {
value
}
}
}
}
}
}
}
Admin takeaway: If a custom UI only needs account IDs and names, GraphQL can request only those fields instead of returning a larger payload.
Example 2: Query Multiple Objects in One Request
Salesforce’s GraphQL API can query multiple objects in one call when the queries are independent.
query AccountContactCaseSummary {
uiapi {
query {
Account(first: 10) {
edges {
node {
Id
Name { value }
Industry { value }
}
}
}
Contact(first: 10) {
edges {
node {
Id
Name { value }
Email { value }
}
}
}
Case(first: 10) {
edges {
node {
Id
CaseNumber { value }
Priority { value }
Status { value }
}
}
}
}
}
}
Admin takeaway: This pattern can reduce the number of client-server round trips for screens that show related summaries. However, if one query depends on a value returned by another query, Salesforce recommends separate calls or supported relationship/semi-join patterns.
Example 3: Filter Results with where
GraphQL filters use object-specific filter types such as Account_Filter.
query ActiveCustomerAccounts {
uiapi {
query {
Account(
first: 25,
where: {
and: [
{ Name: { like: "Acme%" } },
{ Type: { eq: "Customer" } }
]
}
) {
edges {
node {
Id
Name { value }
Type { value }
}
}
pageInfo {
hasNextPage
endCursor
}
}
}
}
}
Admin takeaway: Confirm whether filtered fields are filterable in Salesforce object documentation. Some fields are not supported in where filters.
Example 4: Query Parent Relationships
A child-to-parent query can pull selected parent fields without a separate API call.
query ContactsWithAccountOwner {
uiapi {
query {
Contact(first: 20) {
edges {
node {
Id
Name { value }
Email { value }
Account {
Name { value }
Owner {
Name { value }
}
}
}
}
}
}
}
}
Admin takeaway: This is one of GraphQL’s most practical benefits for custom components: one query can return the record and the related information the user needs to see.
Example 5: Query Parent-to-Child Relationships
Parent-to-child relationships use connection patterns as well.
query AccountsWithContacts {
uiapi {
query {
Account(first: 10) {
edges {
node {
Id
Name { value }
Contacts(first: 5) {
edges {
node {
Id
Name { value }
Email { value }
}
}
}
}
}
}
}
}
}
Admin takeaway: GraphQL can be a good fit for account overview pages, portal summaries, and dashboards that need a small number of related records. It is not a substitute for bulk reporting or data warehouse extraction.
Example 6: Use Optional Fields to Avoid Permission Failures
In API v65.0 and later, optional fields can make queries more resilient when users do not have access to every field.
query UsersWithOptionalEmployeeNumber {
uiapi {
query {
User(first: 10) {
edges {
node {
Id
Name { value }
EmployeeNumber @optional {
value
}
}
}
}
}
}
}
If the user has access to EmployeeNumber, Salesforce returns it. If not, the query can still succeed and omit the inaccessible field.
Admin takeaway: Optional fields are valuable for components used by multiple profiles or permission sets. They do not replace proper security design, but they reduce brittle user experiences.
Example 7: Paginate Results
GraphQL returns the first 10 results by default. Use first, pageInfo, and cursors to paginate.
query PaginatedAccounts($after: String) {
uiapi {
query {
Account(first: 50, after: $after) {
edges {
cursor
node {
Id
Name { value }
}
}
pageInfo {
hasNextPage
endCursor
}
totalCount
pageResultCount
}
}
}
}
Admin takeaway: Require pagination for lists. Do not approve custom components that attempt to retrieve unlimited record sets for an interactive screen.
Practical Use Cases Admins Should Prioritize
1. Lightning Web Components That Need Several Related Records
If a custom component currently calls Apex or REST multiple times to assemble one screen, ask whether GraphQL can return the needed data in one request. This can simplify code and improve perceived performance.
2. Experience Cloud and Embedded Portals
Portal users often have narrower permissions, different field access, and higher sensitivity to page load time. GraphQL’s permission-aware field access and optional fields can help teams build more resilient experiences.
3. Dynamic Record Summaries
GraphQL can retrieve records, selected field values, current user information, metadata, and layouts through the UI API family. That makes it useful for dynamic summaries where the UI needs both data and context.
4. API Modernization Reviews
When reviewing old SOAP or overbuilt REST integrations, GraphQL should be one option in the evaluation matrix. The goal is not to force GraphQL everywhere; the goal is to choose the most maintainable API for the business process.
Common Mistakes to Avoid
- Treating GraphQL as a full REST replacement. GraphQL is excellent for certain read and UI patterns, but Salesforce has many specialized APIs for a reason.
- Ignoring UI API object support. If the object is not supported by UI API, it is not available for GraphQL API querying.
- Testing only as a system administrator. Permission behavior must be tested with actual user profiles and permission sets.
- Forgetting query limits. Relationship depth, subqueries, and record limits still matter.
- Using GraphQL for bulk extraction. Use Bulk API 2.0 or appropriate data tooling for high-volume movement.
- Modernizing data access without modernizing authentication. SOAP
login()retirement risk is primarily an authentication and lifecycle issue.
Admin Review Questions for Developers and Vendors
Use these Q&A prompts in project reviews.
Q: What user context does the GraphQL query run under?
A: GraphQL API requires an access token and follows Salesforce permissions for the context user. Admins should know which user, profile, permission sets, and connected app policies apply.
Q: Which objects and fields does the query access?
A: Ask for the exact query or a documented field list. This supports security review, change impact analysis, and troubleshooting.
Q: Why GraphQL instead of REST?
A: A good answer usually mentions fewer round trips, related data retrieval, dynamic UI needs, or precise response shape. If the answer is only “GraphQL is newer,” push for a better design rationale.
Q: What happens if the user lacks field access?
A: The query should either avoid inaccessible fields, use optional fields where appropriate, or provide a graceful user experience.
Q: How is pagination handled?
A: Lists should use first, after, pageInfo, and cursors. Avoid unbounded data retrieval.
Q: What API version is being used?
A: Salesforce GraphQL endpoints are versioned. Version choice affects available features such as optional fields and mutations.
Q: How will this be monitored after launch?
A: Teams should monitor Salesforce API usage, 503 limit errors, authentication failures, and integration-specific errors.
Recommended 2026 Migration Decision Tree
- Is the current integration using SOAP
login()? - Yes: prioritize authentication remediation with OAuth/external client app patterns.
- No: continue to API-pattern review.
- Is the workload high-volume data movement?
- Yes: evaluate Bulk API 2.0 or data pipeline tooling.
- No: continue.
- Is the workload a UI or app screen needing related Salesforce data?
- Yes: evaluate GraphQL.
- No: continue.
- Is the workload simple CRUD or a straightforward SOQL-style query?
- Yes: REST may be the simpler choice.
- No: continue.
- Is the workload metadata, deployment, or developer tooling?
- Yes: use Metadata API, Tooling API, or Salesforce DX tooling.
- Is a vendor involved?
- Yes: require a written roadmap for SOAP
login()retirement, supported OAuth flows, and target API versions.
Best Practices for Salesforce Admins
- Keep an API inventory as a living asset. Update it whenever a connected app, integration user, vendor connector, middleware flow, or custom component changes.
- Standardize connected app governance. Know who owns each connected app and why it exists.
- Require API version review in release governance. Old versions are a future support risk.
- Use sandbox testing with realistic users. Permission-sensitive APIs can behave differently outside admin profiles.
- Create an integration readiness score. Grade each integration by business criticality, API type, auth method, vendor dependency, documentation quality, and test coverage.
- Document GraphQL queries near the component or integration they support. Future admins should not have to reverse-engineer data access.
- Partner with developers early. GraphQL design is strongest when admins define the business data need and developers optimize the query shape.
FAQ: Salesforce GraphQL API in 2026
What is Salesforce GraphQL API?
Salesforce GraphQL API is a versioned Salesforce API that lets clients query UI API-supported Salesforce data and metadata with GraphQL. It can retrieve a precise data shape from a single endpoint.
Is Salesforce GraphQL better than REST?
GraphQL is better than REST when a UI or app needs several related pieces of Salesforce data in one structured response. REST is often better for simple CRUD, broad resource access, and straightforward integration patterns.
Does GraphQL replace SOAP API for Salesforce?
No. GraphQL does not directly replace every SOAP use case. The SOAP login() retirement should trigger an integration review. Some workloads may move to REST, some to Bulk API, some to middleware, and some UI-shaped reads may move to GraphQL.
Does Salesforce GraphQL respect field-level security?
Yes. Salesforce GraphQL API respects object-level and field-level permissions for the context user. Optional fields can help queries succeed when a user lacks access to a non-critical field.
What objects can Salesforce GraphQL query?
Salesforce GraphQL API can query objects supported by UI API, including custom objects that are available to the context user. Always verify object support before designing a query.
What are the main Salesforce GraphQL limits admins should know?
GraphQL queries follow SOQL-like limits. Each query can contain up to 10 subqueries, each subquery counts as one request for rate limiting, each subquery can return up to 2,000 records, and the first 10 records are returned by default unless pagination arguments are used.
Should admins learn GraphQL syntax?
Admins do not need to become full GraphQL developers, but they should understand the basic query shape, permission behavior, pagination, and when GraphQL is the right API choice. That knowledge improves vendor reviews, security reviews, and project outcomes.
Conclusion: Make GraphQL Part of Your API Readiness Plan
Salesforce GraphQL API deserves a place in your 2026 admin toolkit because it solves a real problem: modern Salesforce experiences often need a precise, permission-aware set of related data without excessive API round trips. At the same time, the SOAP login() retirement timeline makes API governance more urgent.
The right response is not “move everything to GraphQL.” The right response is to inventory your integrations, modernize authentication, classify each workload, and choose the API that best fits the business process. For many UI-shaped and relationship-heavy use cases, GraphQL will be the best option. For simple integrations, REST may remain the cleanest path. For bulk data, use bulk tooling.
Vantage Point helps organizations assess Salesforce integration risk, modernize API patterns, and build scalable Salesforce, HubSpot, MuleSoft, Data Cloud, and AI-enabled solutions. If your team needs help reviewing SOAP login() exposure, planning a Salesforce API migration, or deciding where GraphQL fits, Vantage Point can provide a complimentary API readiness assessment.
About Vantage Point
Vantage Point helps businesses of all sizes improve CRM, automation, integration, and AI outcomes across Salesforce, HubSpot, MuleSoft, Data Cloud, Anthropic Claude, Aircall, and Workato. Our team designs practical, scalable solutions that connect systems, simplify operations, and help teams get more value from their customer data.
