Discussions

we recently encountered this failure in our automation that calls the \[PUT update OpenAPI](<https://docs.readme.com/main/reference/updateapispecification> spec endpoint > HttpResponseProxy{HTTP/1.1 400 Bad Request [Date: Tue, 06 Jun 2023 17:09:11 GMT, Content-Type: application/json; charset=utf-8, Content-Length: 855, Connection: keep-alive, X-Xss-Protection: 1; mode=block, X-Dns-Prefetch-Control: off, X-Frame-Options: Deny, Strict-Transport-Security: max-age=15552000; includeSubDomains, X-Download-Options: noopen, X-Content-Type-Options: nosniff, X-Powered-By: Express, Warning: 199 - "Authorization token in request should be Base64 encoded", X-Documentation-Url: https://docs.readme.com/main/logs/a33ddb46-ad7a-4428-ae84-d95c842128bf, Etag: W/"357-5mB4EKrmnApLjk3SlNuYpGGDO5c", Vary: Accept-Encoding, Via: 1.1 vegur, CF-Cache-Status: DYNAMIC, Server: cloudflare, CF-RAY: 7d3242f5ce5c30ab-SEA] ResponseEntityProxy{[Content-Type: application/json; charset=utf-8,Content-Length: 855,Chunked: false]} we have been passing `Authorization: Basic $readmeApiKey` as the authorization for some time now and this has been working. I see the cool new <https://docs.readme.com/main/reference/intro/authentication> section of the docs, but this doesn't mention base64 encoding the api key. What stands out to me is the `Warning: 199 - "Authorization token in request should be Base64 encoded"` , which could be fine and unrelated to the failed API call if it's just a warning (unless it is the issue, in which case shouldn't that make this a http status 401?

Hi team. I have swagger 2.0 file <https://prod.truv.com/swagger.json> with one of the definitions like this (excerpt schema): ```json JSON { "definitions": { "EmployerCreate": { "type": "object", "properties": { "company_name": { "description": "Company name", "type": "string", "example": "Facebook Demo" }, "account": { "description": "Bank account info. Used for Direct deposit switching and Paycheck linked lending", "required": [ "account_number", "account_type", "routing_number", "bank_name", "deposit_type" ], "type": "object", "properties": { "account_number": { "description": "Account number", "type": "string", "example": "16002600" }, "account_type": { "description": "\nAccount type:\n\n* `checking` - Checking account,\n* `savings` - Savings account\n\n", "type": "string", "enum": [ "checking", "savings" ], "example": "checking" }, "routing_number": { "description": "Routing number", "type": "string", "example": "123456789" }, "bank_name": { "description": "Bank name", "type": "string", "example": "TD Bank" }, "deposit_type": { "description": "\nDeposit type:\n\n* `entire` - Entire paycheck,\n* `percent` - Percentage of the paycheck,\n* `amount` - Fixed amount from the paycheck\n\n", "type": "string", "enum": [ "entire", "percent", "amount" ], "example": "percent" }, "deposit_value": { "description": "Deposit value", "type": "string", "example": "50.00" } } } } } } } ``` My issue is that when I add this object in the list of object on the page <https://docs.truv.com/reference/orders_create> field "account" always added in the request example. E.g.: ``` curl --request POST \ --url https://prod.truv.com/v1/orders/ \ --header 'X-Access-Client-Id: xxx' \ --header 'X-Access-Secret: sandbox-xxx' \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --data ' { "employers": [ { "account": { "account_type": "checking", "deposit_type": "entire" } } ] } ``` Which is wrong for our logic. Seems like required enums account_type and deposit_type is the case of the behavior. They are truly required when object account is provided. But the account object itself is optional for most of our cases. Any tips on how to suppress auto-adding of the account object? Desired result is: ``` curl --request POST \ --url https://prod.truv.com/v1/orders/ \ --header 'X-Access-Client-Id: xxx' \ --header 'X-Access-Secret: sandbox-xxx' \ --header 'accept: application/json' \ --header 'content-type: application/json' \ --data ' { "employers": [ { "company_name": "Some company" } ] } ``` I tried several combinations of default/example parameters, but only thing that works is to make enums account_type and deposit_type optional (which is wrong for our API). Thank for help in advance!

Please, in the editor, how can I create an inline link (that is, within the text block) that opens in a new tab? `[page](url){:target=“_blank”}` doesn't seem to work.

Hi there! Are there plans to allow users to collapse the sidebar in editing mode? It takes up a large chunk of screen space, especially for users with lower resolutions and/or smaller laptop screens.

after updating readme.io through github using OAS3.0.1 file. I am unable to see the complete request example in readme.io. Please help me to resolve this issue.

We've recently started to use readme.io, and we've run into a problem. It seems that readme.io is unable to render endpoints that include a `parameters` section that `$ref` a file that has already been `$ref` before. When viewing pages for any endpoint that matches the above criteria, the page will show the error code `ERR-JUAMVC` with a message: "This reference guide is currently experiencing difficulties and will be back online shortly." A truncated version of our YML file: ```yaml '/users/{id}': put: parameters: $ref: common/users/uid.yml requestBody: required: true content: application/json: $ref: common/users/update.yml '/users/{id}/resources': post: parameters: $ref: common/users/uid.yml requestBody: content: application/json: $ref: common/users/create_resources.yml ``` In the case above, the file `common/users/uid.yml` is referenced inside two endpoints. The page for `PUT /users/{id}` renders successfully, but `POST /users/{id}/resources`fails to do so. We've tried to use `redocly` to render the same above YAML file and it works without issues, and `rdme openapi:validate` also returns no error. Could you help check what could be the cause of this issue?

Are you planning to add support for other types of API? like SDK documentation?

Seems to be the same issue as <https://docs.readme.com/main/discuss/63f92bb42d5c42027e93b815>. Steps to reproduce: 1. edit a page 2. insert image block 3. click "choose file" and select image Details: - The image is a 30KB / 1000x294 PNG, so it should be within the given size limits - Browser JS console shows a `400` error when `POST`ing to `https://dash.readme.com/api/images/image-upload`. Inspecting the network response shows an error message `Image validation failed: user: Path 'user' is required.` Is there a workaround?

build Unknown error (Cannot read property 'slug' of null). <https://docs.readme.com/main/reference> and include the following link to your API log:

There appears to be a bug in the way ReadMe is rendering descriptions of complex schemas that make use of `allOf` to combine multiple schema and reference objects. The behavior that I'm seeing is the description within the most nested object is being used instead of the description from the top-level object. Suppose your API spec is made up of two files, `sampleSpec.json` and `common.json`. Within those files you have the following sample schema objects defined: ``` # Within sampleSpec.json: "Party": { "title": "Party", "description": "Information about a party", "allOf": [ { "$ref": "common.json#/components/schemas/NameAddress" }, { "type": "object", "properties": { "phone": { "$ref": "common.json#/components/schemas/TelephoneNumber", "description": "Phone number" } } }, { "type": "object", "properties": { "entityType": { "$ref": "common.json#/components/schemas/EntityType" } "email": { "type": "string", "format": "email" } } } ], "type": "object" } # Within common.json: "NameAddress": { "title": "Name and Address", "description": "Individual or business name with address", "required": [ "name1" ], "allOf": [ { "properties": { "name1": { "$ref": "#/components/schemas/String64", "description": "Name line 1" }, "name2": { "$ref": "#/components/schemas/String64", "description": "Name line 2" } }, "type": "object" }, { "$ref": "#/components/schemas/Address" } ], "type": "object" }, "Address": { "title": "Address", "description": "Postal address", "required": [ "line1", "city", "country" ], "properties": { "line1": { "type": "string", "description": "Address line 1" }, "line2": { "type": "string", "description": "Address line 2" }, "line3": { "type": "string", "description": "Address line 3" }, "city": { "type": "string", "description": "City" }, "state": { "type": "string", "description": "State or province" }, "postalCode": { "type": "string", "maxLength": 10, "description": "Postal code" }, "country": { "oneOf": [ { "$ref": "#/components/schemas/Iso3166CountryCode" }, { "type": "string", "description": "Spelled-out country names -or- ISO 3166-2" } ], "description": "Country" } }, "type": "object" }, ``` When rendering the description for Party, I would expect to see _Information about a party_ However, ReadMe is rendering the text as _Postal address_. This is in conflict with ReadMe's docs @ <https://docs.readme.com/main/docs/openapi-compatibility-chart#reference-object>: _Prior to rendering your API documentation all $ref pointers are dereferenced. Additionally, as of OpenAPI 3.1, you can include summary and description fields in addition to the $ref pointer, which will override the summary and description fields of the referenced component. Everything else will be fully dereferenced._