login() is no longer available in API v65.0 and is scheduled to be fully retired for older SOAP versions in Summer ’27.Meta Description: Salesforce GraphQL API examples for admins: when to use GraphQL vs REST or SOAP, key 2026 changes, migration checklist, and query patterns.
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.
You should pay attention if your organization has any of the following:
login() or older API versions.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.
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:
uiapi field is the top-level entry point for record queries, aggregate queries, object metadata, related list metadata, current user data, and layouts.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.
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:
login() and then reads a few records: move authentication to an external client app/OAuth pattern, then evaluate REST or GraphQL for data access.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.
| 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 |
Use this checklist before approving new Salesforce API work in 2026.
login() usage. Ask developers and vendors directly: “Does this integration call SOAP login()? Which API version?”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.
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.
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.
whereGraphQL 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.
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.
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.
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.
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.
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.
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.
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.
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.
login() retirement risk is primarily an authentication and lifecycle issue.Use these Q&A prompts in project reviews.
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.
A: Ask for the exact query or a documented field list. This supports security review, change impact analysis, and troubleshooting.
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.
A: The query should either avoid inaccessible fields, use optional fields where appropriate, or provide a graceful user experience.
A: Lists should use first, after, pageInfo, and cursors. Avoid unbounded data retrieval.
A: Salesforce GraphQL endpoints are versioned. Version choice affects available features such as optional fields and mutations.
A: Teams should monitor Salesforce API usage, 503 limit errors, authentication failures, and integration-specific errors.
login()?login() retirement, supported OAuth flows, and target API versions.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.
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.
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.
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.
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.
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.
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.
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.
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.