Broadleaf Microservices is an API-first, highly extensible framework with over 1,000 endpoints. This includes APIs for shopping, pricing, product details, OMS, and other typical commerce needs. To ensure you can harness its full power, we highly recommend reviewing this documentation.
The Broadleaf Microservices API has operations for both storefront and administrative (product information management - "PIM") needs.
Note
|
"Storefront" generally refers to commerce/customer-facing concepts such as browsing, cart, checkout, etc. "Admin" generally refers to business-admin-user-facing concepts such as catalog management. |
Always remember - you can customize the API’s behavior thanks to the extensible nature of the Broadleaf Microservices framework. If you want to change the implementation of any operation, you can do so. See our Extensibility Article for more information.
Following industry best security practices, our operations are secured using OAuth2. You can learn more about our security setup in the Security Article.
Note
|
Don’t worry if you’re not familiar with OAuth2, as you won’t need to know much to get started! |
All Broadleaf Microservices API operations can be explored through our interactive OpenAPI UI, powered by Swagger UI. To learn more about this interactive UI, please see our OpenAPI UI article.
For hands-on introductory tutorials of how you can make real API requests to a live demo instance in just a few minutes using this UI, please see our API tutorial articles.
To make them easy to discover, understand, and consume, we’ve documented all API operations in yml
files using the OpenAPI 3 Specification Standard (formerly Swagger Specification) created by the OpenAPI Initiative.
Why does this matter to you?
Firstly, the interactive OpenAPI UI (powered by Swagger UI) is actually directly informed by our OpenAPI specification files. This enables its powerful try-it-out functionality.
But wait, there’s more!
In each microservice’s specification page, directly below the title, there’s a link to the actual raw yml
file itself (ex: /api/docs/openapi/auth-api.yml
for the Authentication Service).
You can then download this OpenAPI specification file and feed it to any OpenAPI tooling!
This can be very powerful - for example, there are tools that can accept an OpenAPI specification and generate a client library for it!
Note
|
A lot of our specification files reference other specification files.
For example, the Catalog Service’s catalog-api.yml references files like common-components.yml and catalog-components.yml .
To get those files, you can simply replace the *-api.yml in your browser’s address bar with the name of the other file.
For example, if catalog-api.yml is found at /api/docs/openapi/catalog-api.yml , then you can get common-components.yml at /api/docs/openapi/common-components.yml .
|