fixed typos

bump-sh · Feb 3, 2025 · 8d60e7b · 8d60e7b
1 parent 1065841
commit 8d60e7b
Show file tree

Hide file tree

Showing 5 changed files with 4 additions and 7 deletions.
diff --git 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
@@ -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
@@ -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
@@ -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
@@ -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.