Add list of possible errors to REST API documentation

[cgrimal]

Is your feature request related to a problem? Please describe.

In our application, we want to properly handle the response error when calling the REST API. For instance, in some scenarios, the call to the authorize endpoint /oauth2/auth redirects to our callback URL, with error and error_description parameters. Our problem is that we don't know the list of possible values for these parameters.

Describe the solution you'd like

An exhaustive list of possible error responses for all REST API endpoints.

Describe alternatives you've considered

I've tried reading RFC-6749 (linked in the description of the authorized endpoint) but wasn't able to find such a list.

[aeneasr]

Yes, good idea. It's a bit tricky to document this in Swagger but should nontheless be documented. You can however find a list of all error codes here.

[cgrimal]

Thank you @aeneasr for the link, it is very useful and is quite literally what I as looking for (I tried to dig in the code myself but wasn't able to find it).

[aeneasr]

Nice! If you're down to add this stuff to swagger let me know and I can point you in the right direction!

[idivyanshbansal]

@aeneasr sir If I am going correct then can I continue on this issue? I tried formatting one of my repository files

[github-actions[bot]]

Hello contributors!

I am marking this issue as stale as it has not received any engagement from the community or maintainers for a year. That does not imply that the issue has no merit! If you feel strongly about this issue

• open a PR referencing and resolving the issue;
• leave a comment on it and discuss ideas on how you could contribute towards resolving it;
• leave a comment and describe in detail why this issue is critical for your use case;
• open a new issue with updated details and a plan for resolving the issue.

Throughout its lifetime, Ory has received over 10.000 issues and PRs. To sustain that growth, we need to prioritize and focus on issues that are important to the community. A good indication of importance, and thus priority, is activity on a topic.

Unfortunately, burnout has become a topic of concern amongst open-source projects.

It can lead to severe personal and health issues as well as opening catastrophic attack vectors.

The motivation for this automation is to help prioritize issues in the backlog and not ignore, reject, or belittle anyone.

If this issue was marked as stale erroneously you can exempt it by adding the backlog label, assigning someone, or setting a milestone for it.

Thank you for your understanding and to anyone who participated in the conversation! And as written above, please do participate in the conversation if this topic is important to you!

Thank you 🙏✌️

[aeneasr]

I think this is done now!