How Salesforce shares APIs at scale for a great developer experience

Many things change as your business grows. When you’re an API-first company, developing a strategy for sharing your APIs as you scale is a top priority. Salesforce Developer Advocate Philippe Ozil spoke at Postman Galaxy to share how Salesforce uses the Postman API Platform to continue giving developers a great API experience as the company has grown.

According to Philippe, Salesforce was previously using another tool to manage their APIs, but it lacked the collaboration features they were looking for—which is what led them to Postman. Read on to learn more about how Salesforce uses Postman as part of their API-first strategy.

About Salesforce

If you’re not already familiar with Salesforce, they provide a leading customer relationship management (CRM) and business software development platform. Their platform includes applications for marketing, sales, customer service, IT, and other areas, which help teams work together to provide the best possible experience for their customers. Developers customize these applications, create whole new applications, and integrate Salesforce with other business systems. APIs are one of the key components that make this possible.

Salesforce and Postman

In the same way that the Salesforce platform helps an organization’s teams work together, Postman helps developers in the Salesforce ecosystem work together. Since exposing their API on the Postman platform, Salesforce has seen the following results:

  • Developers can use Postman on the web without needing to install software
  • Developers can reuse their custom request collections on multiple Salesforce orgs
  • Open source community members are able to make contributions through their public workspace

Check out these requests you can use on the Salesforce workspace:

The challenges Salesforce faced

Salesforce provides large, enterprise-scale services and applications. When there are millions of users, billions of transactions per day, and millions of software integrations (both internal, like payroll software, and external, like customer-facing websites), managing the APIs presents a handful of challenges. Those challenges come from the number of APIs, the number of versions in support at the same time, and API signatures that are unique to each customer.

Supporting multiple versions and authentication types

Each API has to support many different versions at the same time. Salesforce continues support for older API versions because customers still use them, and when a breaking change is released, it affects all API consumers. For this reason, APIs are versioned with long-lasting support, including some that are over ten years old. Their APIs also need to support multiple authentication methods, such as OAuth, SAML, and OpenID Connect.

Managing customer-specific API signatures

Different customers can use the same API in entirely different ways. Philippe gave a great example of this, where Customer A is an airline and Customer B is a car rental company. Both customers use the same software to manage their customers’ reservations, and both of them use standard objects such as Account that are exposed through REST resources, including Id, Name, and Account Type standard fields.

Comparison of two customers using the same REST resources with their own custom fields and objects
Comparison of two customers using the same REST resources with their own custom fields and objects

API consumers can extend the standard objects with custom fields to suit their use case, and they can also create custom objects with custom fields on top of them. Each time they do this, they modify the API signature because the custom objects are automatically exposed as REST resources. Custom fields are automatically made available through the API as well. But it doesn’t stop there. Salesforce also allows customers to build custom REST endpoints that serve custom business logic. Customer A can serve a GET endpoint to show a trip summary with different objects like planes, airports, and connections, and Customer B can expose a POST URL to generate reports.

Finding a solution with Postman

Before using Postman, Salesforce was using another tool that provided them with basic operations like exploring and calling Salesforce APIs. As their organization scaled, a need for collaboration among their development teams started to emerge. Using Postman allowed developers to work together across the organization to create and manage Salesforce’s many APIs and reuse API requests in different Salesforce orgs, such as development environments, sandboxes, and production environments.

Onboarding developers faster

Postman allows Salesforce developers to get to work faster. Most of the time, developers working in large enterprises or in regulated industries aren’t administrators of their own machines. Security becomes even more important as organizations grow and their security policies become stricter. This often means that installed software has to be on an allowlist, and getting applications added to the list takes some time. By using the Postman web UI, developers don’t have to install any software and can get started right away.

Improving collaboration

Using Postman to expose their APIs improves collaboration among Salesforce developers. Not only can developers work together on the same APIs, but they can also share resources such as environments, collections, and variables. Maintaining a single source of truth for these resources keeps developers on the same page and saves time—no need to email or message documents back and forth to share context.

Developing a scalable strategy

When developing a new API, Philippe recommends starting small. For their new APIs, Salesforce developers set up basic authentication and support the most frequent operations. When the API is ready, they often ship an early beta to a smaller group of users and iterate based on their feedback.

He also highly recommends getting help from the valuable open source community: “You’re not alone when you build these APIs,” he says. “You’re one of the stakeholders, but also, your users are stakeholders. Building these APIs with Postman or any other tool requires a lot of time and resources, and there are some people that are really willing to help. These people are sitting next to you; they are your community members.”

Maximizing visibility

Salesforce developers publish their APIs in a public workspace and on the Public API Network to maximize their visibility to the community. This gives their own developers and the open source community a central place to make changes to the APIs. Contributors can fork the workspace, make changes, and submit pull requests back to the original workspace for their review.

Work with Salesforce collections

Ready to get started with some Salesforce APIs? Check out the Salesforce Developers public workspace, where you’ll find collections that allow you to perform Salesforce tasks programmatically. You can fork collections for the Salesforce Platform, Marketing Cloud, Commerce Cloud, and more.

Watch the full Salesforce talk

What do you think about this topic? Tell us in a comment below.

Comment

Your email address will not be published. Required fields are marked *


This site uses Akismet to reduce spam. Learn how your comment data is processed.

2 thoughts on “How Salesforce shares APIs at scale for a great developer experience

    Salesforce owns MuleSoft, so why is this tool being used instead, or how is it enhancing the other? Supposedly the Anypoint platform was supposed to provide a number of these capabilities.

    I must say, this blog post on how Salesforce shares APIs at scale truly highlights the remarkable developer experience they offer. As an avid Salesforce user and developer, I have been fascinated by their commitment to delivering top-notch API functionality and their continuous efforts to improve the developer experience.

    The article beautifully outlines how Salesforce has built a robust infrastructure to share APIs efficiently and seamlessly. The adoption of Postman as a collaboration platform is a great choice, as it empowers developers to work collaboratively and simplifies the process of API testing and documentation.

    The emphasis on maintaining clear and comprehensive API documentation is crucial in any developer ecosystem, and Salesforce has done an exceptional job in this regard. Their dedication to providing detailed examples, code snippets, and resources ensures that developers can quickly understand and utilize the APIs effectively.

    I was particularly impressed by Salesforce’s investment in automating the API sharing process. The implementation of CI/CD practices and the incorporation of Swagger to generate API documentation automatically demonstrates their commitment to streamlining development workflows and reducing time-to-market for developers.

    The section on versioning and backward compatibility is a testament to Salesforce’s consideration for developers’ needs. By providing consistent support for deprecated APIs and ensuring seamless transitions to newer versions, Salesforce proves that they understand the importance of maintaining stable and reliable systems.

    Moreover, the insights shared regarding API governance and security are commendable. Salesforce’s dedication to enforcing strict access controls, rate limiting, and comprehensive security measures instills confidence in developers to build robust integrations with their APIs.

    Overall, this blog post has enlightened me on Salesforce’s exemplary approach to API sharing at scale. The developer experience they provide is truly exceptional, and it’s evident that they prioritize the success and satisfaction of their developer community. I look forward to exploring more of Salesforce’s APIs and leveraging their platform to build innovative solutions.

    Kudos to the Salesforce team for their commitment to delivering a great developer experience, and thank you to the blog author for providing valuable insights into Salesforce’s API-sharing practices.
    Sweet Potato Tec