diff --git a/src/_guides/bump-sh-tutorials/try-requests-in-insomnia.md b/src/_guides/bump-sh-tutorials/try-requests-in-insomnia.md index 1ff8f0ae..b84590c4 100644 --- a/src/_guides/bump-sh-tutorials/try-requests-in-insomnia.md +++ b/src/_guides/bump-sh-tutorials/try-requests-in-insomnia.md @@ -5,7 +5,7 @@ excerpt: Integrate your OpenAPI-powered documentation with Insomnia to let custo date: 2024-06-04 --- -> Bump.sh now includes its own [API Explorer](https://docs.bump.sh/product-updates/2025/01/09/api-explorer/), allowing you to test your API directly within your documentation. [Give it a try !](https://bump.sh/demo/doc/api-explorer/explorer/operation/operation-adduser) +> Bump.sh now includes its own [API Explorer](https://docs.bump.sh/product-updates/2025/01/09/api-explorer/), allowing you to test your API directly within your documentation. [Give it a try!](https://bump.sh/demo/doc/api-explorer/explorer/operation/operation-adduser) Seeing how an API works is the first step in an end-users journey to using the API, and the second step is making some test requests to get a feel for how it works. Some people like to do this with code, so code samples will be a good start for them, especially if the API has an SDK. Other people like to do this with interactive HTTP clients, like [Insomnia](https://insomnia.rest). diff --git a/src/_guides/bump-sh-tutorials/try-requests-in-postman.md b/src/_guides/bump-sh-tutorials/try-requests-in-postman.md index 02dcf940..e0f4ed96 100644 --- a/src/_guides/bump-sh-tutorials/try-requests-in-postman.md +++ b/src/_guides/bump-sh-tutorials/try-requests-in-postman.md @@ -5,7 +5,7 @@ excerpt: Integrate your OpenAPI-powered documentation with Postman to let custom date: 2024-05-14 --- -> Bump.sh now includes its own [API Explorer](https://docs.bump.sh/product-updates/2025/01/09/api-explorer/), allowing you to test your API directly within your documentation. [Give it a try !](https://bump.sh/demo/doc/api-explorer/explorer/operation/operation-adduser) +> Bump.sh now includes its own [API Explorer](https://docs.bump.sh/product-updates/2025/01/09/api-explorer/), allowing you to test your API directly within your documentation. [Give it a try!](https://bump.sh/demo/doc/api-explorer/explorer/operation/operation-adduser) Seeing how an API works is the first step in an end-users journey to using the API, and the second step is making some test requests to get a feel for how it works. Some people like to do this with code, so code samples will be a good start for them, especially if you have an SDL. Other people like to do this with interactive HTTP clients, like [Postman](https://postman.com/). diff --git a/src/_guides/openapi/specification/v3.1/introduction/benefits.md b/src/_guides/openapi/specification/v3.1/introduction/benefits.md index ab67d261..66389f39 100644 --- a/src/_guides/openapi/specification/v3.1/introduction/benefits.md +++ b/src/_guides/openapi/specification/v3.1/introduction/benefits.md @@ -67,7 +67,6 @@ There are many tools to help you get the most out of OpenAPI, at every step of t ### Testing -* [Bump.sh](https://bump.sh/api-documentation) 💙 * [Microcks](https://microcks.io/) * [Postman](https://www.postman.com/api-platform/api-testing/) diff --git a/src/_guides/technical-writing/api-documentation-checklist.md b/src/_guides/technical-writing/api-documentation-checklist.md index 267a6c04..b96c7877 100644 --- a/src/_guides/technical-writing/api-documentation-checklist.md +++ b/src/_guides/technical-writing/api-documentation-checklist.md @@ -80,7 +80,7 @@ Congrats - you launched your API! But just because you have launched your API do - [ ] Step-by-step tutorials for common workflows or use cases. - [ ] Link to Postman collection or similar tool for API exploration and testing. -> Bump.sh now includes its own [API Explorer](https://docs.bump.sh/product-updates/2025/01/09/api-explorer/), allowing you to test your API directly within your documentation. [Give it a try !](https://bump.sh/demo/doc/api-explorer/explorer/operation/operation-adduser) +> Bump.sh now includes its own [API Explorer](https://docs.bump.sh/product-updates/2025/01/09/api-explorer/), allowing you to test your API directly within your documentation. [Give it a try!](https://bump.sh/demo/doc/api-explorer/explorer/operation/operation-adduser) ### 14. **Reference Applications** - [ ] Provide sample applications or integrations that use the API. diff --git a/src/_guides/technical-writing/the-role-of-technical-writer-in-api-documentation.md b/src/_guides/technical-writing/the-role-of-technical-writer-in-api-documentation.md index 24e66357..c8d655f8 100644 --- a/src/_guides/technical-writing/the-role-of-technical-writer-in-api-documentation.md +++ b/src/_guides/technical-writing/the-role-of-technical-writer-in-api-documentation.md @@ -22,9 +22,7 @@ I’ve personally experienced tremendous value by involving technical writers ea For technical writers who have a software developer background, the transition to API documentation is seamless. However, technical writers who have been more product or user-focused may find themselves quickly learning the essentials of APIs. This may include learning how HTTP works, how to leverage YAML and the OpenAPI Specification to capture API reference details, and how to author with asciidoc or markdown rather than XML-based authoring tools such as oXygen. -Technical writers also benefit from learning how to use API client tools, such as Postman, Insomnia, and Hoppscotch. Command-line tools such as cURL may also be useful but aren’t always necessary as it depends on the preferences of the intended audience that will use the API. - -> Bump.sh now includes its own [API Explorer](https://docs.bump.sh/product-updates/2025/01/09/api-explorer/), allowing you to test your API directly within your documentation. [Give it a try !](https://bump.sh/demo/doc/api-explorer/explorer/operation/operation-adduser) +Technical writers also benefit from learning how to use API client tools, such as Bump.sh, Postman, Insomnia, and Hoppscotch. Command-line tools such as cURL may also be useful but aren’t always necessary as it depends on the preferences of the intended audience that will use the API. They also benefit from learning source control systems such as git or platforms such as GitHub and GitLab to better manage their artifacts and integrate with continuous integration pipelines. Understanding workflows around these systems is also important, including branching and forking documentation for upcoming releases without negatively impacting existing documentation.