# Consuming Mastercard APIs in Client Applications
source: https://developer.mastercard.com/blog/consuming-mastercard-apis-in-client-applications/index.md

Authors: Jean-Alexis Aufauvre. If you are a developer and have been using Mastercard services in the past few years, there is a big chance you added Mastercard SDKs (Software Development Kits ) to your applications. SDKs really are quick wins. They are regular client code libraries pushed to public software repositories (Maven Central, NuGet, NpmJs, Packagist, etc.) with which you can get a response from a Mastercard service in a matter of minutes. For that, our documentation pages provide ready to be used code samples in the SDK language API, and the SDK handles everything for you: environment (stage, sandbox, production), security (authentication and encryption), transport, error handling. Before continuing with what we call "SDKs as a Service", some of the challenges SDKs present and new ways of consuming Mastercard APIs in applications, let's first talk a bit about what makes all of this possible: API specifications. Mastercard Uses Schema-First API Design Internally, Mastercard promotes not only an API-first approach, but also a schema-first API design approach. It means every development team must work on a service API before coding its implementation, and thus every service is supposed to be born from an OpenAPI specification (formerly Swagger), a file describing in details the service API and what to expect from it. Using a schema-first API design has many advantages. Instead of jumping straight into the code, it allows teams to focus on what matters: the product (in our case an API) and the user experience (in our case the Developer eXperience). It encourages discussing the facade before diving into the internals, and help extracting true requirements and use-cases. In addition to that, an OpenAPI specification can be versioned, shared, and thus easily reviewed. It can be visualized and analysed to check it matches our company standards. Finally, it can be used to give internal teams or Mastercard customers early previews, and to ease development tasks by generating some code for you (server stubs, client libraries, or test cases). It's common to see people rejecting API design, associating it to BDUF (Big Design Up Front) and explaining spending time on design is not agile, that the API should be designed later on, during the development sprints. But unless your API is for a pet store , don't expect a fancy API to emerge from nowhere! It's so easy to overlook the design and be stuck forever with an API nobody really wanted and that would require considerable efforts to be fixed. But let's go back to how we use API specifications on the client side. Existing SDKs Present Some Challenges SDKs as a Service is the possibility for Mastercard teams to generate SDKs for their API products "for free", provided they have a ready to be used and compliant OpenAPI specification stored in Git. From a company perspective, the team behind the Mastercard Developer platform did a great job at designing and providing a set of tools and pipelines to automatically generate, test, and release SDKs as soon a service requires an SDK update (more information can be found in Bryan O'Sullivan's post here ). But if we have seen SDKs considerably simplifying integrations, automated SDK generation and the SDKs themselves present some challenges when used in real-life projects. Here are four of them. Closed source software Because most of the code is generated and doesn't change after that, we didn't realize the value of having the SDK projects publicly available. A consequence of not giving access to the source-code is SDKs are hard to approve when banks or financial institutions undergo audits or certifications. And troubleshooting and debugging is not as easy as it should be. Too generic programmatic interface In the search for a solution for SDKs to be automatically and consistently generated, tested and documented, the team introduced a generic programmatic interface based on maps. With this approach, everything needed to build requests and handle responses is seen as a list of keys and value strings. If a loosely typed interface definitively brings advantages (for instance the fact adding new fields doesn't necessarily require an SDK upgrade), it can be a bit unnatural when used in combination with strongly typed languages. And because IDEs can't "autocomplete", developers have no other choice but to fall back to online API documentations. Another unexpected side-effect of hiding REST APIs and resources behind an unified map interface is it tends to encourage poor API designs. Small monoliths with dependencies Dependency hell is well-known by developers. By trying not to reinvent the wheel, we add many dependencies to our projects, for taking advantage of only a few utility functions. That's why we often see small libraries depending on a pile of dependencies (and transitive dependencies) even bigger than the library itself. Because SDKs are created with Swagger Codegen and custom templates, they happen to share many dependencies with client applications. We discovered this can cause some headaches. One simple example is a customer application that was using a very old version of Apache Commons Codec (from 2009) whose Base64 encoder changed in a non-backward compatible way, "from multi-line chunking (commons-codec-1.4) to single-line non-chunking (commons-codec-1.5)". The result was one of our Java SDK was generating invalid Authorization headers, causing all requests to be rejected. Additionally, SDKs use their own HTTP client, logger and cryptographic implementations, and those can't be customized. "One shape to fit them all" and weak ownership Generated SDKs provide a basic one-to-one mapping with service endpoints, when we could expect them to bring more value on the client side (implementation of use-cases, additional controls, etc.). Also, because SDKs are created "magically", they are considered a black box by many. For those two reasons, a few development teams raised the idea of owning both the API and the corresponding client SDK. So is there a way to overcome those limitations? The conclusion the team reached was we could make OpenAPI specifications first-class citizens of the Mastercard Developers platform to allow developers to consume APIs the way they prefer. You Can Now Generate Your Own API Clients As seen previously, tools are available for generating code from API specifications. For instance, OpenAPI Generator creates customizable API client libraries in multiple languages and frameworks, and everything is included out of the box. To complement this, Mastercard developed new client authentication and encryption libraries you can start to integrate to your API client projects. Here are some advantages those libraries present when compared to SDKs. Open-source reference implementations The software is developed on GitHub, in the open, so that libraries can easily be audited or used as reference implementations. Each of them comes with a public change log, public daily builds, public Sonar reports, and the discussion happens in GitHub issues and pull requests. In case developers don't want to use the packages Mastercard releases, they can simply reuse the source code (published under the MIT license) and even have the possibility to contribute to their development. Small building blocks with a single purpose You can see those libraries as small building blocks. They are focused on providing the authentication and encryption bits ("do one thing and do it well"). This makes them easier to test and to maintain. Minimal required dependencies We chose to follow a zero-dependency policy for the different library projects. It means no dependencies are used unless absolutely necessary, and we only take advantage of the target frameworks and platforms. That way, the packages stay as thin as possible. Extended platform and framework support Creating brand new and small projects allowed us to maximize the platform support. For instance, the .NET libraries embrace .NET standard and can be used with all the .NET implementations in a cross-platform fashion. Another example is our .NET assemblies are strong-named (a security requirement some of our customers have). We were unable to strong name our SDKs (as it represents a breaking change), and customers unfortunately had to sign the SDK assemblies themselves. A final example is the support for a new language: Swift. In conclusion, the Mastercard Developers platform keeps evolving, and again, we bring new possibilities for making Mastercard API consumption easy while giving more freedom and options to developers. Developers can still use our SDKs, but from now on they also have the opportunity to generate their own API client libraries from OpenAPI specifications and use our new authentication and encryption client libraries as building blocks. We encourage you to start generating your own Mastercard API client library right away. You can use our revisited guides and tutorials as starting point: Using OAuth 1.0a to Access Mastercard APIs Securing Sensitive Data Using Payload Encryption Generating and Configuring a Mastercard API Client