Client Libraries Overview

    Overview

    Client libraries will help you quickly integrate your application with FusionAuth. All of our client libraries are open source and hosted on our GitHub account. You can fork and tweak them as well as look over the code to learn how the client libraries work.

    If we are missing a language, open a GitHub Issue as a Feature Request if you don’t see it already listed as an open feature.

    There are also community contributed client libraries for other languages.

    Usage Suggestions

    FusionAuth client libraries are a bit different than full featured SDKs that you might have encountered before. They are a thin wrapper around the REST API. Client libraries are typically used in two different ways.

    First, they can be used to access the FusionAuth APIs in a familiar format, leveraging language features like auto-completion. When used for this, they can be helpful to script FusionAuth configuration, automate common tasks, and create copies of existing applications, groups and more.

    To use the client libraries effectively in this way, it is helpful to review the source code of the client library and the API documentation, which contains the JSON structure. The API documentation is very thorough about the JSON objects it expects as part of the payload as well as what parameters are required when.

    Second, client libraries can exchange a token to let a user to log in via the Authorization Code Grant. This is a secondary use of these libraries. This process is best done by using a language specific OAuth library, which will work with FusionAuth. Here is a community curated list of such libraries.

    Client libraries do not currently provide higher level functionality such as token management. Here is an open issue detailing some requested higher level functionality. Please feel free to file an issue or upvote this one if you desire it.

    You can always directly call the REST API if the client library functionality doesn’t work for you. All the client libraries use the REST API.

    In general, the request object will either be string parameters or a complex object depending on the type of API call being made. Any request object will be mapped by the library to a JSON object required by the corresponding API method. Examining the API documents for the operations you’re trying to call will therefore be useful, especially if you are using language without static typing.

    The response object will typically contain:

    • a status corresponding to the HTTP status code returned by the API. It may also be -1 if no HTTP request was successfully made

    • a JSON success object if the call succeeded.

    • a JSON error object with an intelligible message if the status code is 4xx or 5xx.

    • an exception object if there was no HTTP request sent or there was no reasonable response from the server.

    Feedback

    How helpful was this page?

    See a problem?

    File an issue in our docs repo