# Get Help

Got issues, questions, suggestions? Please read this page carefully to understand how you can get help working with RestSharp.

# Questions

The most effective way to resolve questions about using RestSharp is StackOverflow.

RestSharp has a large user base. Tens of thousands of projects and hundreds of thousands of developers use RestSharp on a daily basis. So, asking questions on StackOverflow with restsharp (opens new window) tag would most definitely lead you to a solution.


Please do not use GitHub issues to ask question about using RestSharp.

# Discussions

We have a mail list (opens new window) at Google Groups dedicated to discussions about using RestSharp, feature proposals and similar topics. It is perfectly fine to ask questions about using RestSharp at that group too.

Please check the group and engage with the community if you feel a need to discuss things that you struggle with or want to improve.

# Bugs and issues

The last resort to get help when you experience some unexpected behaviour, a crash or anything else that you consider a bug, is submitting an issue at our GitHub repository.


Please do not ignore our contribution guidelines, otherwise you risk your issue to be closed without being considered. Respect the maintainers, be specific and provide as many details about the issue as you can.

Ensure you provide the following in the issue:

  • Expected behaviour
  • Actual behaviour
  • Why do you think it is an issue, not a misunderstanding
  • How the issue can be reproduced: a repository or at least a code snippet
  • If RestSharp unexpectedly throws an exception, provide the stack trace

# Contributing

Although issues are considered as contributions, we strongly suggest helping the community by solving issues that you experienced by submitting a pull request.

Here are contribution guidelines:

  • Make each pull request atomic and exclusive; don't send pull requests for a laundry list of changes.
  • Even better, commit in small manageable chunks.
  • Use the supplied .DotSettings file to format the code.
  • Any change must be accompanied by a unit test covering the change.
  • New tests are preferred to use Shoudly.
  • No regions except for license header
  • Code must build for .NET Standard 2.0 and .NET Framework 4.5.2.
  • Test must run on .NET Core 3.1 and .NET Framework 4.5.2
  • Use autocrlf=true (git config --global core.autocrlf true [http://help.github.com/dealing-with-lineendings/])

You can also support maintainers and motivate them by contributing financially at Open Collective (opens new window).