Conversation
Signed-off-by: Charan Kamarapu <kamarapucharan@gmail.com>
There was a problem hiding this comment.
Pull request overview
This PR adds documentation for configuring authentication in Keploy's API testing feature. The new guide explains how to set up authentication mechanisms (Login API and Bearer Token) for test generation and execution.
Changes:
- Added comprehensive authentication setup guide covering login API and bearer token methods
- Updated sidebar navigation to include the new auth setup documentation
Reviewed changes
Copilot reviewed 2 out of 5 changed files in this pull request and generated 8 comments.
| File | Description |
|---|---|
| versioned_docs/version-4.0.0/running-keploy/api-testing-auth-setup.md | New documentation page explaining authentication setup for API testing with Login API and Bearer Token options |
| versioned_sidebars/version-4.0.0-sidebars.json | Added entry for the new auth setup documentation in the running-keploy section |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| <ProductTier tiers="Free, Teams, Scale, Enterprise" offerings="Self-Hosted, Dedicated" /> | ||
|
|
||
| This guide will help you setup your application Auth in API Test Generation and Run |
There was a problem hiding this comment.
When "setup" is used as a verb, it should be two words: "set up". The noun form "setup" is correct when used as a noun (e.g., "Auth Setup" in the title), but when describing an action, it should be "set up".
| This guide will help you setup your application Auth in API Test Generation and Run | |
| This guide will help you set up your application Auth in API Test Generation and Run |
|  | ||
|
|
||
|
|
||
| This Auth option is for the application which provides a login API. The testing platform will execute this login API when ever the auth token is required and use it in the API calls either in generation or run. |
There was a problem hiding this comment.
"when ever" should be written as one word: "whenever".
| This Auth option is for the application which provides a login API. The testing platform will execute this login API when ever the auth token is required and use it in the API calls either in generation or run. | |
| This Auth option is for the application which provides a login API. The testing platform will execute this login API whenever the auth token is required and use it in the API calls either in generation or run. |
|
|
||
| This Auth option is for the application which provides a login API. The testing platform will execute this login API when ever the auth token is required and use it in the API calls either in generation or run. | ||
|
|
||
| JWT Token - The platform will execute this API and take the token from the json response value with the key "token" or "access_token" or "jwt" |
There was a problem hiding this comment.
For consistency with technical documentation standards, "json" should be capitalized as "JSON" when referring to the data format.
| JWT Token - The platform will execute this API and take the token from the json response value with the key "token" or "access_token" or "jwt" | |
| JWT Token - The platform will execute this API and take the token from the JSON response value with the key "token" or "access_token" or "jwt" |
|
|
||
| This Auth option is for the application which provides a login API. The testing platform will execute this login API when ever the auth token is required and use it in the API calls either in generation or run. | ||
|
|
||
| JWT Token - The platform will execute this API and take the token from the json response value with the key "token" or "access_token" or "jwt" |
There was a problem hiding this comment.
For consistency with technical documentation standards, "jwt" should be capitalized as "JWT" when referring to the authentication token type.
|
|
||
|  | ||
|
|
||
| This Auth option is for the application which can be authenticated using jwt token. This token is used in all the API calls that are done by the platform to the application. |
There was a problem hiding this comment.
For consistency with technical documentation standards, "jwt" should be capitalized as "JWT" when referring to the authentication token type.
| This Auth option is for the application which can be authenticated using jwt token. This token is used in all the API calls that are done by the platform to the application. | |
| This Auth option is for the application which can be authenticated using JWT token. This token is used in all the API calls that are done by the platform to the application. |
| - webhooks | ||
| - integration | ||
| - custom validation | ||
| - policy enforcement | ||
| keywords: | ||
| - webhook | ||
| - API testing | ||
| - PreExecute | ||
| - PostExecute | ||
| - external validation | ||
| - custom logic |
There was a problem hiding this comment.
The tags in the frontmatter are not relevant to authentication setup. These tags ("webhooks", "custom validation", "policy enforcement") appear to be copied from the webhook documentation. The tags should reflect the authentication-related content of this document, such as "authentication", "auth", "bearer token", "login API", etc.
| - webhooks | |
| - integration | |
| - custom validation | |
| - policy enforcement | |
| keywords: | |
| - webhook | |
| - API testing | |
| - PreExecute | |
| - PostExecute | |
| - external validation | |
| - custom logic | |
| - authentication | |
| - auth | |
| - bearer token | |
| - login API | |
| keywords: | |
| - authentication | |
| - auth | |
| - bearer token | |
| - login API | |
| - JWT | |
| - cookie | |
| - access token |
| - webhooks | ||
| - integration | ||
| - custom validation | ||
| - policy enforcement | ||
| keywords: | ||
| - webhook | ||
| - API testing | ||
| - PreExecute | ||
| - PostExecute | ||
| - external validation | ||
| - custom logic |
There was a problem hiding this comment.
The keywords in the frontmatter are not relevant to authentication setup. These keywords ("webhook", "PreExecute", "PostExecute", "external validation", "custom logic") appear to be copied from the webhook documentation. The keywords should reflect the authentication-related content of this document, such as "authentication", "bearer token", "JWT", "login", "auth setup", etc.
| - webhooks | |
| - integration | |
| - custom validation | |
| - policy enforcement | |
| keywords: | |
| - webhook | |
| - API testing | |
| - PreExecute | |
| - PostExecute | |
| - external validation | |
| - custom logic | |
| - authentication | |
| - auth setup | |
| - JWT | |
| - bearer token | |
| keywords: | |
| - authentication | |
| - auth setup | |
| - login | |
| - JWT | |
| - bearer token | |
| - cookie auth |
|
|
||
| import ProductTier from '@site/src/components/ProductTier'; | ||
|
|
||
| <ProductTier tiers="Free, Teams, Scale, Enterprise" offerings="Self-Hosted, Dedicated" /> |
There was a problem hiding this comment.
The tier specification uses "Teams" but other documentation files in this repository use "Team" (without the 's'). For consistency, this should be "Team" to match the pattern seen in api-testing-cicd.md and generate-api-tests-using-ai.md which use "Free, Team, Scale, Enterprise".
Signed-off-by: Charan Kamarapu <kamarapucharan@gmail.com>
2 participants
This pull request adds documentation for setting up authentication in API testing for Keploy, making it easier for users to understand how to configure auth mechanisms during test generation and execution. It also updates the sidebar to include this new guide.
New documentation:
api-testing-auth-setup.mdthat explains how to set up authentication for API testing, including login API and bearer token methods.Documentation navigation update:
version-4.0.0-sidebars.json) to include the new "Auth Setup" documentation under the "running-keploy" section.