API Designer Collection Validation Incorrect with Body field value

🙋 Help
1

When I have an API spec in OpenAPI 3.0 in yml format, with the following section defined, the collection validation indicates an error that the body parameters in JSON format should be removed from the collection even though the API Spec and Collection both show that it should be there. The ‘username’ field’s value is showing up with a random value, different value in each request that this issue is showing up in.

The collection was generated from the API Spec without modification before validating through API Designer.

API Spec Snippet:

/resetpassword:
    post:
      summary: Reset Password
      operationId: resetPassword
      security:
        - authorizer: []
      requestBody:
        content:
          application/json:
            schema:
              $ref: "#/components/schemas/ResetPasswordRequest"
            example:
              username: "{{USER_NAME}}"
              oldPassword: "{{PASSWORD}}"
              newPassword: "{{NEW_PASSWORD}}"
        required: true
      responses:
        200:
          description: "200 response"
          content: 
            application/json:
              schema:
                $ref: "#/components/schemas/ResetPasswordResponse"
              example:
                status: 200
                code: 2003
                message: "Password reset successfully."
    ...
    components:
      schemas:
        ResetPasswordRequest:
          title: "Reset Password Request Schema"
          required:
          - "username"
          - "oldPassword"
          - "newPassword"
          type: "object"
          properties:
            username:
              pattern: "^[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+$"
              type: "string"
            oldPassword:
              type: "string"
            newPassword:
              type: "string"
    ...

Collection Request for ResetPassword Body:

{
    "username": "<string>",
    "oldPassword": "<string>",
    "newPassword": "<string>"
}

Environment with variable defined for:
USER_NAME
with value as email format.

Collection Validation Web Page for ResetPassword:

image
image1374×321 9 KB

Thank you for your time and help.

2

Hi @darren.capner

Current suggested change you see is due to body not adhering to schema. As username has pattern defined in schema which is being violated in collection request.

You can Import your API and tweak generated collection based on some option from Import flow. You can start by following Import button on top left corner and choose corresponding method.

Once you select schema, you will be able to select options in Configuration model. Choose example for Request parameter generation and Example parameter generation options. This will use example adhering to schema as value instead of default type placeholders (which are useful for documentation purpose).

image
image1586×1208 103 KB

We are working on Configuration model in Generate Collection flow from API tab. But for now you can link API and Imported Collection from API tab and validate again.

3

Yes, you are right in that the request body attribute ‘username’ is not following pattern defined in API schema. I can change the value to a string with the right format and the validation passes. This is good.

The problem that I see when I set the ‘username’ JSON body attribute value to reference an Environment variable “{{USER_NAME}}”. the validation fails with the same message. This issue has been reported in this post. Collection Validation errors when request contains variables

Reset Password Request Body:

{
    "username": "{{USER_NAME}}",
    "oldPassword": "{{PASSWORD}}",
    "newPassword": "{{NEW_PASSWORD}}"
}

I click validate on the collection in the API Designer and receive this message.

image
image1371×312 10.3 KB

4

Yes, this is something that we are working on where collection/environment variables will not result in validation error. This is something that is already available in header, query params and path variable, while request/response body is still in progress.

Thanks for reporting this.

1 Like
5

@darren.capner This should be fixed now.