Category

Blog

Assertible Joins the OpenAPI Initiative

By | Blog

We’re proud to announce that Assertible – API and website performance testing and uptime monitoring company – as the latest member to join to OpenAPI Initiative.

Assertible enables businesses of all shapes and sizes to confidently monitor the quality and stability of their APIs, allowing for faster iteration and development cycles without compromising correctness in the applications. Utilizing the OpenAPI Spec has proven to be a big advantage for teams by providing a way to communicate the intent, functionality, and purpose of their APIs from documentation, to development, and testing.

“Today, I’m proud to announce that Assertible is the latest member to join to OpenAPI Initiative. We’re thrilled to be a part of the initiative and join the ranks of great teams working to pave the way for the future of the internet,” Assertible’s CTO Cody Reichert says. “As developers, testers, and business-minded people ourselves, we plan on sharing our insight and experience with the OpenAPI Initiative team, and importantly, representing a segment of the market that is often overlooked: testing and quality assurance.”

After working with hundreds of teams and thousands of developers, it became apparent to the Assertible team that adopting OpenAPI is advantageous for multiple reasons. By joining the OpenAPI Initiative, they hope to both give back to the API community as well as learn about more use-cases creating a higher quality web for the future to enjoy.

“At Assertible, we view the OpenAPI Initiative as a critical component in creating and sustaining a coherent ecosystem that will allow developers, businesses, and the general population to benefit, advance, and utilize the backbone of the web: APIs. Not only does the OAI provide a foundation for rapidly creating and integrating otherwise disparate services, it also advances the entire community, from creators to consumers, by providing a unified starting point for discussion and future development, which has proven worthwhile and unfettered by rapid changes in technologies. We’re excited to be a part of pushing the industry forward. Reichert says.

Assertible and OpenAPI

Assertible is pleased to announce it has added support for OpenAPI v3 and has been working with the OAS and its predecessor the Swagger Spec since the company’s inception in 2015. Currently, it’s possible to create a fully automated test suite from a simple, or complex, specification.

We plan on continuing to extend our support to include support for features – like JSON Schema, examples, and more – to pave the way for 100% automated test coverage using OpenAPI. If you have any thoughts or requests for extending OAS support in Assertible, we’d love to hear them.

Thoughts? Let’s talk!

Want to talk about how Assertible and OpenAPI can improve you development cycle, or have any feedback on us joining the OpenAPI Initiative? We’d love to hear from you:

Reach out on Twitter, or
Send us an email

OpenAPI Initiative Community Day Schedule at IBM INDEX

By | Blog

Schedule

  • PHASE I – Intro – 9-10:30
    • 9-9:15 Welcome
    • 9:15-9:30
      • Intros
    • 9:30-10:30
      • Ron Ratovsky
        • Intro OAS
        • New features OASv3
        • Future features
        • Questions
    PHASE II – Lightning talks -10:30-11:30
    • 10:30-11:00/11:30
      • Using Swagger for your OAS needs – Ron Ratovsky
      • And more
    PHASE III -11:30-12:45
    • Intro to specs
      • Jonathan Stoikovitch
    • API Fundamentals
      • Erik van Zijst
    • API tooling – Testing/Documentation
      • Joyce LinChristopher ReichertNicolas Grenié
    • How to contribute to OAS development
      • Marsh Gardiner
      • Ron Ratovsky
    • Implementation coaching
      • Michele Titolo
    PHASE IV – Wrap UP
    • Erin McKean
      • Be an OAS Evangelist

9:00 AM-01:00 PM | Tuesday, Feb. 20
Moscone West/Level 2, Room 2018
OpenAPI Initiative Community Day


Attend Community Free (Tuesday only) – With promo code [CD1OPENAPI]

OpenAPI Community Leads

Ron Ratovsky

SmartBear

Ask me about ...

- OASv3
- Codegen
- Contributing to the OAS

Erin McKean

IBM

Ask me about ...

- Convincing your team to go OAS
- OAS implementations

Jonathan Stoikovitch

Mulesoft

Ask me about ...

- All things API specs
- How to love OAS and RAML at the same time

Michele Titolo

Capital One

Ask me about ...

- API Design
- Contract testing
- Building tools that use the OAS

Nicolas Grenié

RedHat

Ask me about ...

- open source API designer
- interactive documentation for APIs
- imports from an OpenAPI spec

Joyce Lin

Postman

Ask me about ...

- Testing and automation
- API documentation
- Monitoring the health of my APIs

Erik van Zijst

Atlassian

Ask me about ...

- API Architecture
- RESTful design
- Hypermedia.

Marsh Gardiner

Google

Ask me about ...

- API Design
- API Management
- History of the OAI
- OpenAPI Spec evolution
- How to contribute to the OAS

Christopher Reichert

Assertible

Ask me about ...

- API testing (in a CI/CD pipeline)
- monitor for breaking API changes
- generate an automated test suite from an OpenAPI definition
- communicate API changes within your team

OpenAPI Initiative to Host Community Day as part of IBM INDEX 2018 DayZero

By | Blog

The Open API Initiative is partnering with founding member IBM to host a half day of OpenAPI Spec events at the 2018 IBM INDEX developer conference taking place Feb. 20-22.

Bring your API, leave with an OpenAPI Spec! Experts and community members will be on hand for a four-hour hack space to help you create an OpenAPI spec for your API! Learn about the 3.0 spec, tooling, documentation and code generation, and more, and then create an OpenAPI spec for your own API!

Taking place the day before the start of IBM INDEX, affectionately referred to as DayZero is free event and the best chance for the API Community in the SF Bay Area – and those flying in to attend the full IBM INDEX event – to learn from premier implementers of the OAS.

The thinking behind DayZero of IBM INDEX was for big blue to take a step back and let the developer communities that make up the larger ecosystem we are a part and showcase the talent that is the magic behind the code. Best of all it is free, not only to the attendees but to the communities running the sessions.

We’ll see you on February 20.

09:00 AM-01:00 PM | Tuesday, Feb. 20
Moscone West/Level 2, Room 2018
Session type: Community Meeting


Attend Community FREE (one-day only) - With promo code [CD1OPENAPI]



Register here

OpenAPI Community Leads

Ron Ratovsky

SmartBear

Ask me about ...

- OASv3
- Codegen
- Contributing to the OAS

Erin McKean

IBM

Ask me about ...

- Convincing your team to go OAS
- OAS implementations

Jonathan Stoikovitch

Mulesoft

Ask me about ...

- All things API specs
- How to love OAS and RAML at the same time

Michele Titolo

Capital One

Ask me about ...

- API Design
- Contract testing
- Building tools that use the OAS

Nicolas Grenié

RedHat

Ask me about ...

- open source API designer
- interactive documentation for APIs
- imports from an OpenAPI spec

Joyce Lin

Postman

Ask me about ...

- Testing and automation
- API documentation
- Monitoring the health of my APIs

Erik van Zijst

Atlassian

Ask me about ...

- API Architecture
- RESTful design
- Hypermedia.

Marsh Gardiner

Google

Ask me about ...

- API Design
- API Management
- History of the OAI
- OpenAPI Spec evolution
- How to contribute to the OAS

Christopher Reichert

Assertible

Ask me about ...

- API testing (in a CI/CD pipeline)
- monitor for breaking API changes
- generate an automated test suite from an OpenAPI definition
- communicate API changes within your team

aapi, API Management Provider, Joins the Open API Initiative

By | Blog

API management provider aapi joins as the 30th member of the Open API Initiative to coincide with the debut of their API portal announced on Nov. 28.

“APIs are reforming the digital landscape and OAI is enabling this transformation through the standardization of API language,” aapi CTO Timothy Arvanites said. Easing the connectivity of systems, the OpenAPI Specification is the foundation for the interoperability and simplicity of the aapi platform. We are proud supporters of open source, the Linux Foundation, and especially OAI and look to a world where APIs are made easy.”

aapi hosts an open library of over 3000 OpenAPI/Swagger files and its platform is designed to streamline API development and management processes by reducing costs, complexity and API learning curves. aapi was founded by Craig Lund, Timothy Arvanites, and Robert Phillips. Lund serves as chairman and CEO, while Arvanites is the Chief Technology Officer.

Open API Initiative Welcomes API Testing and Monitoring Company API Fortress as its Newest Member

By | Blog

The Open API Initiative is pleased to welcome API Fortress, an automated API testing and monitoring platform, as the latest company to join the OAI.

“A major part of validating API quality is testing,” Patrick Poulin, API Fortress CEO and cofounder shares, “and that step can be almost entirely automated with a strong spec file format. We are excited to contribute directly to the OpenAPI Spec and continue to advance the API-driven economy.”

API Fortress, founded in 2014, is focused on make API testing and monitoring easier. Achieving that without diminishing the level of detail is tricky, but there is a silver bullet – automation. Using an OAS file, the platform can diminish the level of effort in building a detailed test by 90%. By joining the board, we hope to be part of the process in getting that to 99% for every platform.

“Thankfully, rigorous unit testing is now an active part of development. However, functional integration testing of APIs is often procrastinated,” says CTO Simone Pezzano. “It is always on the plan for next quarter, because the level of effort to achieve complete coverage is overwhelming. That is what we have been specifically working to solve, and spec formats like the OAS are how we’ve been able to get so close to full automation.”

Patrick Poulin
Open API BGB Rep
Patrick grew up doing construction, which was the family business. Throughout that time he found himself preferring constructing digital homes over real ones. He eventually started his tech career building the first mobile websites for Fortune 500 companies such as Target and Macy's, and is now focused on making companies take API testing as seriously as they take website and application testing.

IBM is a Platinum Sponsor at API Strategy & Practice Conference

By | Blog

The API Strategy & Practice Conference is approaching – it’s taking place in Portland on Oct 31- Nov 2. I’m thrilled to get to go to another API Strategy conference, my last one being in Austin 2015. This time around, I’ll be speaking!

Brief introduction from me – my name is Sai Vennam and I’m a Developer Advocate at IBM. I’m a big fan of Node.js but also play with Java and Go quite a bit. I love speaking about technology that I’m passionate about; that especially includes APIs.

If you’re attending, be sure to check out my talk on Wednesday on “Building Serverless APIs for Modern Application Architectures”. In the modern era of software development, businesses are using the latest and greatest technologies like serverless functions. However, they still have to support legacy systems and software. I’ll be talking about hybrid application architectures that have spawned from these requirements and specifically how serverless APIs fit in.

Serverless is rapidly picking up traction and IBM is at the forefront of this adoption. We’ve been developing our serverless capabilities completely in the open-source as an Apache project – OpenWhisk. You can also take advantage of the capabilities on IBM Cloud Functions.

In addition to the session, I’ll also be at the booth with the talented Erin McKean and other fellow IBMers to talk to you about your newest API projects!

Did you know IBM is a founding member of the Open API Initiative? Learn more about the latest OpenAPI Spec v3.0.0 release.

We hope to see you in Portland! Be sure to come by the IBM booth.

Learn more about IBM Cloud : https://www.ibm.com/cloud-computing/bluemix/.

About the Author

Sai Vennam
IBM Bluemix Developer and Advocate
I’m a passionate developer with the drive to work on the newest technology. My position in IBM allows me to work with the latest cloud technology, such as Docker and Cloud Foundry. In addition, I actively work to enable developers using our cloud, IBM Bluemix, by writing blogs, creating videos and engaging online and local communities. I primarily work with Node.js, which has been rapidly rising in support; it is arguably the most popular next-gen language for developing web applications.

Fostering Ecosystem-Driven Innovation, The OAI Welcomes SAP as a New Member

By | Blog

The Open API Initiative (OAI) project is pleased to announce that SAP has joined as our newest member. The OAI community is working to establish an open source foundation for developing interoperability of APIs. SAP joins 28 current members in promoting a vendor-neutral description format. OAI is hosted by The Linux Foundation, the nonprofit advancing professional open source management for mass collaboration.

“It is a testament to the shared vision of the API community and the effectiveness of open source that Global 500 companies like SAP, IBM and Google can get together and collaborate on the OpenAPI Specification along with tool providers like SmartBear and end users like Capital One,” said Ole Lensmar, OAI project chair and CTO at SmartBear.

OAI launched in 2015 to standardize how APIs are described. The recently released OpenAPI Specification v3 defines the interfaces for RESTful APIs, describing resources and operations in a format that is easily discoverable and understandable by both machines and humans. For more information about the project and specification, visit https://www.openapis.org/.

“SAP is committed to openness and choice for our customers,” said Björn Goerke, CTO of SAP and president of SAP Cloud Platform at SAP. “SAP uses machine-readable Open API specifications for our enterprise APIs. We believe this fosters ecosystem-driven innovation on top of our SAP Cloud Platform.”

SAP continues its commitment to the open source community, having previously joined transformative Linux Foundation projects such as Cloud Foundry, Hyperledger and Node.js Foundation.

Three common scenarios for leveraging the OpenAPI Specification

By | Blog

This article is a short preview of the forthcoming talk “Designing APIs with the OpenAPI Specification” to be delivered at Codemotion conference, Madrid, Spain on November, 24th.


We, as developers, are surrounded by powerful and amazing APIs. Just finding the time to integrate the interesting services to enhance our product could be a daunting task just because time is the scarcest resource we have as developers.

API integration is a recurrent pain for developers because frequently we feel like frustrated plumbers trying to connect pipes of different sizes and materials, forced to create custom adapters and junctions over and over again. You already know the feeling, don’t you?

We are already living in fast times where the API-economy drives much of technology innovation. Platforms like Amazon, Paypal, Stripe, Heroku, and Google Maps to cite a few, are good examples of successful platforms and products that are leaders in their respective markets, creating ecosystems around them. If you own the ecosystem, you win the game. APIs have a story to tell: good APIs – easy to consume by third-parties  – can help further adoption. We, the developers as API consumers, decide in many occasion which APIs succeed and which ones are not used anymore.

In this context of rapid innovation, API discovery, and easy integration is key for every new service on town. In this field is where the OpenAPI Spec can help the most.

OpenAPI Spec provides a solid standard for describing interoperable REST APIs based on resources and HTTP. This description is useful for two types of audiences: humans and machines.

  • Humans use the specification as a source of API documentation, examples and as a guide to try out and understand the capabilities of the API. Easy of use is the key factor here for succeed.
  • Machines use the specification for creating code able to talk the service protocol in the language of your developments. Reducing in this way the hard plumbing work described before and minimizing the cost and needs for platform specific SDKs.

In my experience, there are three major use cases for using OpenAPI Spec on your API project: legacy APIs, contact-first driven, and server-first driven. Let’s review them one by one.

1. Legacy API

The first scenario covers services and APIs that are already in production. Adding an OpenAPI document will formally capture the signature of the API in a standardized way. Therefore, consumers can use this contract as documentation to easily integrate with your API.

 

As long as you are using HTTP or HTTPS with JSON or XML encoding, it doesn’t matter what language or framework you choosed for the implementation: you have an interoperable API awaiting to be discovered by the world.

 

The best thing here that surprise many people is: you don’t have to change a single bit of your running API or service. The metadata provided by the OpenAPI Spec is a contract stored in a self-contained file (YAML or JSON) you can share offline (as a file) or publish in any web server.

Adding the contract will not change a bit of your legacy implementation, but will help developers out there to try and consume your API.

2. Contract-first driven API

To speed up developments, it is frequent to work in parallel in two teams: back-end and front-end. Both can build their stuff in parallel if they agreed to an API contract. Front-end people usually create and use mock-ups of the contract to be able to work without having to be waiting for the back-end to be ready.

OpenAPI and related tools here provide good tooling for this task. The OpenAPI contract can be edited and validated with no language or implementation assumptions (making the API really very, very interoperable).

Then, using OAS code-gen tools both teams can generate skeletons for the server-side and proxies for the frontend in any supported language or platform.

I recomend this way of working when the main functionality is clear enough to be able to design the contract up-front.

In the long-term you will maintain and evolve the contract in a planned manner. So this is the recommended approach in the long-run for a high quality API contract.

Note: a clear versioning strategy is important in order not to break old clients when a new version arrive.

3. Server-first driven API

In other type of projects, developers can decide to build their API directly on their favourite language and platform and derive the API contract later, as a direct consequence of the running implementation. This scenario is also supported by the OpenAPI Spec. An specific library for the target language is employed. Using reflection techniques and metadata to discover services, types, parameters directly inspecting the source code to automatically generate an OAS compliant spec on the fly.

This approach has some advantages:

  • Auto-generated documentation and contract.
  • Contract is always in sync with service implementation.
  • Agility in server-side development.

Major cons of the approach:

  • Be diligent when evolving the service, you could inadvertently break existing clients.
  • Derived contract could lack of simplicity or UX (if compared with a contract first). What is optimized for automation could be confusing for humans: design for humans.

NOTE: I recommend the server-first approach when the requirements and design is changing fast and your team is iterating to find the right contract design. Being not yet in production, this will alleviate breaking the clients. In any case, fully review your final API contract and refactor for a better UX before launching it.

Conclusion

OpenAPI provides an interoperable way of describing an API:

  • formally enough to be consumed by machines and
  • KISS enough to be used by developers to document and learn the API.

The three scenarios described provide flexibility to fit with different project needs. Honestly, I think this is the main feature of the OpenAPI precursor, known as Swagger, got right from the very beginning: adapting well to very different development scenarios and different project development stages.

Software engineering is still a young discipline if compared with plumbing or electrical engineering. We need standards that helps us to deal with and automate repetitive tasks. That’s why, I think whatever you are, a machine or a human, exposing APIs with the OpenAPI Spec is a good thing to have in your public API!

If you liked this post and want to know more about it, join my talk at Codemotion in Madrid at November 24th and let’s deep dive on it!


About the author

 

Pedro J. Molina

Pedro J. Molina holds a PhD. in Computer Sciences from the Technical University of Valencia. After working in different product companies related to Modeling and Code Generation he set up a startup called Metadev with focus on tooling for microservices and cloud development. Twitter: @pmolinam

Scale an OpenAPI based web API with Google Cloud Endpoints

By | Blog

With the recent announcement of OpenAPI Specification v3, it’s the right moment to pause and think for a moment about the benefits of using an API contract to describe your Web API. With an open and freely accessible, computer-friendly format, it opens up very important perspectives around tooling, compatibility, or team collaboration, as well as foster a fruitful ecosystem.

The benefits of using an OpenAPI Specification (OAS) to describe your API

In a nutshell, the API contract is the source of truth. Whether you’re the one implementing the API backend, or you’re the consumer calling the API, there’s this central contract that each party can rely on, to be certain how the API should be looking like, what kind of endpoint to expect, what payloads will be exchanged, or which status codes are used.

With a central contract, team communication and collaboration is facilitated: I’ve seen customers where a central architecture team would define a contract, that was implemented by a third-party (an outsourcing consulting company), and the API was consumed by different teams, both internally and externally. The central contract was here to facilitate the work between those teams, to ensure the contract would be fulfilled.

In addition, having such a computer-friendly contract is really useful for tooling. Out of the contract, you can generate various useful artifacts, such as:

  • static & live mocks — that consumers can use when the API is not finalized,
  • test stubs — for facilitating integration tests,
  • server skeletons — to get started implementing the business logic of the API with a ready-made project template,
  • client SDKs — offering kits consumers can use, using various languages, to call your API more easily,
  • sandbox & live playground — a visual environment for testing and calling the API, for developers to discover how the API actually works,
  • an API portal with provisioning — a website offering the API reference documentation and allowing developers to get credentials to get access to the API,
  • static documentation — perhaps with just the API reference documentation, or a bundle of useful associated user guide, etc.

However, be careful with artifact generation. As soon as you start making some customizations to what’s been generated by tools, you might run the risk of overwriting those changes the next time you re-generate those artifacts! So beware, how customization can be done and be integrated with those generated artifacts.

Presentation on scaling an OpenAPI Spec-based web API

InfoQ recently released a video from the APIDays conference that took place in Paris last year. I talked about scaling an OpenAPI Spec-based web API using Cloud Endpoints, on the Google Cloud platform.

I spoke about the topic a few times, as web APIs is a topic I enjoy, at Nordic APIs, at APIDays, or Devoxx. But it’s great to see the video online. So let me share the slide deck along with the video:

You can also have a look at the slide deck embedded below:


In my presentation and demo, I decided to use Cloud Endpoints to manage my API, and to host the business logic of my API implementation on the Google Cloud Platform. GCP (for short) provides various “compute” solutions for your projects:

  • Google App Engine (Platform-as-a-Service): you deploy your code, and all the scaling is done transparently for you by the platform,
  • Google Container Engine (Container-as-a-Service): it’s a Kubernetes-based container orchestrator where you deploy your apps in the form of containers,
  • Google Compute Engine (Infrastructure-as-a-Service): this time, it’s full VMs, with even more control on the environment, that you deploy and scale.

In my case, I went with a containerized Ratpack implementation for my API, implemented using the Apache Groovy programming language (what else? :-). So I deployed my application on Container Engine.

I described my web API via an OpenAPI descriptor, and managed it via Cloud Endpoints. Cloud Endpoints is actually the underlying infrastructure used by Google themselves, to host all the APIs developers can use today (think Google Maps API, etc.) This architecture already serves literally hundreds of billions of requests everyday… so you can assume it’s certainly quite scalable in itself. You can manage APIs described with OpenAPI, regardless of how they were implemented (totally agnostic from the underlying implementation), and it can manage both HTTP-based JSON web APIs, as well as gRPC based ones.

There are three interesting key aspects to know about Cloud Endpoints, regardless of whether you’re using the platform for public / private / mobile / micro-services APIs:

  • Cloud Endpoints takes care of security, to control access to the API, to authenticate consumers (taking advantage of API keys, Firebase auth, Auth0, JSON Web Tokens)
  • Cloud Endpoints offers logging and monitoring capabilities of key API related metrics
  • Cloud Endpoints is super snappy and scales nicely as already mentioned (we’ll come back to this in a minute)

Cloud Endpoints actually offers an open source “sidecar” container proxy. Your containerized application will go hand in hand with the Extensible Service Proxy, and will actually be wrapped by that proxy. All the calls will actually go through that proxy before hitting your own application. Interestingly, there’s not one single proxy, but each instance of you app will have its own proxy, thus diminishing the latency between the call to the proxy and the actual code execution in your app (there’s no network hop between the two, to a somewhat distant central proxy, as the two containers are together). For the record, this proxy is based on Nginx. And that proxy container can also be run elsewhere, even on your own infrastructure.

Summary

In summary, Cloud Endpoints takes care of securing, monitoring and scaling your Web API. Developing, deploying, and managing your API on Google Cloud Platform gives you the choice: in terms of protocol with JSON / HTTP based APIs or gRPC, in terms of implementation technology as you can chose any language or framework you wish that are supported by the various compute options of the platform allow you to go from PaaS, to CaaS, or IaaS. Last but not least, this solution is open: based on open standards like OpenAPI and gRPC, or by implementing its proxy on top of Nginx.

With an open format like OpenAPI Specification to describe APIs, all the stakeholders working with APIs can collaborate together and reap the following benefits.

First of all, it’s easier for teams to work effectively together, as all the members can rely on the API description to be the truth representing what the API should look like. It’s particularly true when one team designs the contract, while another team, potentially external, implements the contract. There’s one source of truth describing the API, easing communication in the team.

Secondly, as a computer-friendly and well specified format, it’s possible to automate various tasks, like generating mocks, client libraries, server skeleton, and more. You can also use that specification to check that an implementation complies with the contract.

Lastly, with an open and freely accessible format, an ecosystem of vendors, of open source projects & developers, can collaborate together, preventing lock-in effects, allowing API developers to take advantage of tools and solutions that are compatible together via the OpenAPI Specification.

eBay Joins the Open API Initiative

By | Blog

The partnership makes it easier for eBay developers to integrate with our RESTful public APIs and evolve their buying and selling experiences on our platforms.

For more than 20 years, eBay has been a leading marketplace, connecting shoppers to their perfect item from more than 1.1 billion listings on our platform and providing opportunities for sellers to grow their businesses. Today, I’m proud to announce our membership in the Open API Initiative (OAI). This partnership will focus on the OpenAPI Specification, making it easier and faster for eBay developers to integrate with eBay’s RESTful public APIs as we evolve the buying and selling experience on eBay. This opportunity leverages technology to make it easier for our developer ecosystem to create new eBay experiences.

The OAI is an open source project under the Linux Foundation. These software projects are independently funded and are geared toward harnessing the power of collaborative development across industries and ecosystems. OAI is the most popular open source framework for defining and creating RESTful APIs, with tens of thousands of developers using the tools.

As a member of OAI, we are continuing to tap into our developer ecosystem and grow eBay’s APIs, by expanding our developer community and encouraging building to creating a more integrated platform and shopping and selling seamless experiences on eBay. Earlier this year, we we kicked off eBay Connect with seven developer events across the world to give external developers insights into our platform and encourage their innovation. And last year, eBay Developers Program revamped our API platform with 13 new standards-based APIs.

This partnership and our new APIs make it simpler for our developers and sellers to quickly integrate with eBay and onboard all their inventory—part of our promise to deliver the most powerful commerce platform to our seller and developer partners so they can build sophisticated integrations to manage all end-to-end selling operations on eBay and easily scale their business.


Gail Frederick
eBay representative on the Business Governing Board
Gail Frederick is Senior Director of Developer Ecosystem and Services at eBay, where she strives to disrupt commerce with innovative ideas to create more powerful buying and selling experiences on eBay.