[Swagger][Documentation] - Field should be marked as optional

[AliSot2000]

Describe the bug

The field chatId in the WAHASessionPresence Model is set as required. However, using POST /api/{session}/presence in conjunction with presence online or offline returns the following: HTTP_Error 400

{
  "detail": "'offline' presence works on the global scope and doesn't require 'chatId' field."
}

Version

{
  "version": "2024.6.8",
  "engine": "NOWEB",
  "tier": "PLUS",
  "browser": "/usr/bin/chromium"
}

Suggested Solutions:

• Mark the field as optional and provide a description indicating that it mustn't be set if the presence is online or offline.
• Don't return a Error 400 and just ignore the chatId in the backend if the presence is online or offlline
• Split the endpoint into two one for global presence and one for chat presence.

[AliSot2000]

Also, I would like to add that I think Errors in the documentation, especially in openapi.json should count as bugs because the OpenAPI standard makes this file almost equivalent to code.

I can generate 90% of the python code I need to interact with your service from that file. Errors in that file translate to bugs in the generated code I'm using. Consequently I'd argue that it should also count as bugs. I wouldn't make that case if you provided a description of the API using natural language.

But as it stands, I was hoping to wrap your entire api within one evening. But I keep running into issues with not documented errors, not documented request or response models and requests and responses that don't adhere to the specification you provide etc.

And in my humble opinion, I think it would have been an enrichment if your service had a python wrapper ready to go with it.

[devlikepro]

@AliSot2000 hi! Thank you for your feedback, it is very valuable to us! :heart_hands: Could you contact me at Discord please devlikeapro., I didn't manage to find your contacts :disappointed: :pray:

[devlikepro]

would have been an enrichment if your service had a python wrapper ready to go with it.

Yes, you're right, it'd be great to have complete openapi that we could use to generate all clients for major languages and sdk, hopefully we'll have that in the future :crossed_fingers:

[devlikepro]

Could you contact me at Discord please

or [email protected]