ContributionsMost RecentMost LikesSolutionsRe: Persistence of Integrations at the API (not version) and organizational levels I also would find this feature useful - particularily the templating - as I want to do this: sync each API with a folder in the same repo in Git Azure DevOps with the path /APIs/<<API_NAME>>/<<Version>>, presently I will need to configure each one of these separately. Thanks. Re: SoapUI Pro - OAS3 - Swagger Compliance Assertion does not respect the Nullable flag Hello I have re-tested this bug on ReadyAPI 2.8.0 and I can confirm it is fixed. Thanks Re: SoapUI Pro - OAS3 - Swagger Compliance Assertion does not respect the Nullable flag Thanks I have raised this with support and have recieved the reply below: -----Original Message----- From: SmartBear Customer Care <customercare@smartbear.com> Sent: 29 January 2019 16:52 To: xxxxxxxxxxxx Subject: Case #00334467: SoapUI Pro - OAS3 - Swagger Compliance Assertion does not respect the Nullable flag Hello, We have an existing defect for this issue of RIA-8020 with the swagger compliance schema assertion and nullable values. You will be notified when this defect is fixed. Regards, Mxxxx --------------------------------------------------------------- 01/28/2019 05:44:06 PM EST [Mxxx Jxxx] --------------------------------------------------------------- SoapUI Pro - OAS3 - Swagger Compliance Assertion does not respect the Nullable flag I am currently evaluating SmartBear's toolset for suitability for my company - specifically SoapUI Pro for automated API testing of our large suite of APIs which are in described in OAS3 format - and I have hit on this issue. When importing the following (example) OAS3 specification in SoapUI Pro: openapi: "3.0.0" info: version: 1.0.0 title: Swagger Petstore license: name: MIT servers: - url: http://petstore.swagger.io/v1 paths: /pets: get: summary: List all pets operationId: listPets tags: - pets responses: '200': description: A paged array of pets content: application/json: schema: $ref: "#/components/schemas/Pets" components: schemas: Pet: required: - id - name properties: id: type: integer format: int64 name: type: string tag: nullable: true type: string Pets: type: array items: $ref: "#/components/schemas/Pet" That uses theSchema Object "Nullable" field for the "tag" property of the pet model. And creating a stub of the service in ServiceV the returns the following response on GET /pets (with "tag" set to null): [ { "id" : 0, "name" : "string", "tag" : null } ] When I run the tests against the stub I receive the following error from the Swagger Compliance Assertion: instance type (null) does not match any allowed primitive type (allowed: ["string"]) checked node: [/0/tag] corresponding schema: [/items/properties/tag] It seems like the swagger compliance check is not respecting the new OAS3 "nullable" field, as according to the spec "tag" is nullable so my response is valid. My real services have a large number of nullable fields so I would need this to be working in order to adopt SoapUI as my preferred API testing solution. Any help appreciated. Version of ReadyAPI I am trialling: ReadyAPI 2.6.0 Build Date: 2019-01-14T14:47:06Z(2261) 57460326ed5636e3c392e5981c683c817f5091d8 Here are some resources I looked at when investigating this issue: *https://assertible.com/docs/guide/assertions#create-json-schema-assertions-for-openapi-v3-responses *https://github.com/OAI/OpenAPI-Specification/issues/1368 PS If this is a bug should I raise it elsewhere? Solved