The Salesforce API Journey: A Deep Dive

Salesforce is often cited as a trailblazer in the API economy, a model for how a company can use APIs not only to drive its own growth but to redefine an industry. However, its API journey is not just a story of technical innovation — it’s one of strategic foresight, timely cultural shifts, and an ever-evolving commitment to customer value.

Below, we’ll explore Salesforce’s history with APIs, the pivotal moments that marked its transformation, and how its API strategy continues to shape its business today.

The Early Days: Products and Platforms

In order to understand why the Salesforce API journey is important, we must understand what that landscape looked like in the early years. In the 2000s, internet companies were largely protective over their processes — you often had to work through an agent or a representative, and even then, you were quite limited in what you could do. The businesses that did have APIs largely consigned them to internal tooling and systems, treating them more like infrastructure rather than a business offering.

When Salesforce launched its SOAP API in 2000, this conceptualization of what an API was — let alone the business it drove — was changed entirely on its head. The 2000s were a time of change in the API space – Roy Fielding’s doctoral dissertation would establish the REST API standard in short order, and many companies were riding the dotcom boom, offering more and more functionality across the ever-widening popular world wide web.

Salesforce saw this as a potential avenue for its own product. If they could take their CRM (customer relationship platform) and offer a public API, they theorized, then developers could build applications and integrations that would push the ecosystem forward in a way that no one company could possibly match on its own. For the modern API developer, this seems an obvious path forward, but it was quite a unique point of view at the time.

After the API was released in 2000, this rapidly proved to be the case. Although the initial SOAP API was quite complex, boasting a PDF manual of several hundreds of pages, it offered groundbreaking functionality, setting an industry path forward for how services might be leveraged and expanded. This made Salesforce a platform rather than solely a consumer product, attracting developers to grow the ecosystem.

Also read: Exploring Salesforce’s Journey With CIAM A Cultural Shift: The Bezos Mandate, Salesforce-Style

In 2002, a now-famous letter would circulate at Amazon: the so-called Bezos Mandate. It was quite a simple edict — every team should expose its data and functionality through an API. While this was internally focused, Salesforce’s approach to its API would be based on the same thought pattern, shifting from a product-first to an API-first design philosophy.

As an example of the thought process Salesforce held at the time, the company famously launched a media campaign that declared “The End of Software,” promising to provide a product as a service rather than a simple software license.

In essence, Salesforce followed a principle that diversified its product offering into something more than the individual will of the organization. By bringing in other developers, Salesforce created opportunities to iterate and develop externally while aligning its internal teams against the concept of driving business success via the API design.

This focus on APIs caused a significant cultural shift — APIs as a business driver. The SOAP API that Salesforce first launched, which would later be iterated upon, was a game-changing sea change. The idea of shifting the API strategy in this way wasn’t just an enhancement of existing offerings — it was an entirely new line of business and one that was a complete shift from the previous idea of locking functionality behind agents and salespeople.

Allowing developers to form a marketplace where Salesforce-integrated solutions would be accessible was an entirely new ecosystem and one that would drive additional billions in revenue and increased customer retention.

More on the Bezos API Mandate: Amazon’s Manifesto For Externalization The Current State of APIs at Salesforce

Today, Salesforce boasts thousands of apps in its AppExchange, connecting untold billions of dollars in transactions, scheduling events, managing reporting and sales commissions, and much more, forming Salesforce into a dominant figure in the industry. Salesforce, recognizing the limitations of the high complexity behind its SOAP APIs, has added additional functionality with GraphQL and RESTful builds. After acquiring Mulesoft in 2018, Salesforce extended its API capabilities, offering new tools for API-first integration and development.

This has shown the real power of a solution like that at Salesforce. It’s all well and good to build a powerful product, but if you can’t extend that product — build upon it and offer additional features through third party offerings — then you are limited in your potential. Offering an API ecosystem will typically be more lucrative than providing an API product, and Salesforce has proven that in spades.

The Future of APIs at Salesforce

Looking ahead, Salesforce’s API strategy will likely continue to evolve. Areas like artificial intelligence through large language models and real-time data streaming are taking the API space by storm, and Salesforce is already investing heavily in these spaces.

As time goes on, Salesforce’s APIs will need to adapt to support even more granular, composable, and AI-friendly services, and in many ways, these movements will stand as a bellwether for the industry as a whole.

Lessons for the Industry

Salesforce’s journey offers several lessons that can benefit organizations across multiple industries. Firstly, this story is about strategic positioning. Organizations originally treated APIs as technical artifacts facilitating internal operation and development. The Salesforce journey proved that APIs are strategic assets — systems that enable business development and growth, let alone innovation. This shift in mindset applies across the board and is reflected in the times that followed the Salesforce API launch. eBay, Flickr, Amazon — all of these providers moved towards offering APIs as their own product and business, and they have proven these moves are intelligent.

The second big takeaway is the idea of building an ecosystem rather than a product. A product is ephemeral in many ways. It serves what it was meant to serve when it was created. Therefore, the features are limited to that time and mindset. Even when it can be updated, this comes with a cost, and highly efficient movement often comes with its own headaches. Salesforce shows that no developer is better than all the developers in the industry, so opening up your product to an ecosystem approach will be better than not.

Finally, Salesforce showed that governance and federation are key facilitators of this process. When it launched its API, it quickly realized it needed new functionality to widen the herd, so to speak. Adopting Mulesoft was the most recent example, but Salesforce has invested time and time again in building strong governance and federation into their product, allowing for secure permutation and development while ensuring the core product remained secure and trusted. The best ecosystem in the world will fail if nobody trusts it enough to use it, and Salesforce is an excellent example of what can happen when you do things right.

Final Thoughts

We hope you have found this case study helpful. Salesforce continues to show great promise, and organizations should take these lessons to heart as they move into the next phase of the industry, their offering, and the API space as a whole.