Helper Libraries and SDKs


Use one of our helper libraries to use Clarify in your language of choice:

It’s dangerous to go alone. The helper libraries handle authentication, the HTTP aspects, and even wrap commonly needed functionality in language-specific constructs. You can focus on your app.

We provide helper libraries in the languages we use on a regular basis. While we’re open to creating and adding more, we want to know which ones you care about. Email us to tell us what you need!

Dive into our Quickstarts to explore what is possible with the libraries.


SDK Writing Guide

Our goal is to provide helper libraries in the most relevant languages as quickly as possible but sometimes our roadmap doesn’t match your timeline. Fear not! Here are some tips and information to get you started.

In terms of helper library design, we see four layers:

  • Authentication/Connectivity
  • Response/Result handling
  • Domain Models
  • Framework-specific opinions

In our language libraries, we will only deal with the first two layers. The final two layers should be handled by framework/domain-specific libraries built on top of our libraries. If you do build something, let us know so we can give show off your efforts on this page!

Here are some general guidelines to get you started:

  • MUST be idiomatic with the language in which it is written. For example, a C# library will use data structures and patterns common to that platform.
  • MUST follow the commonly accepted coding standards of the language in which it is written.
  • MUST handle authentication, connectivity, and responses in a consistent manner.
  • SHOULD have behavior tests to demonstrate it works as described.
  • SHOULD pass along errors as appropriate for the language.
  • MUST NOT hide errors from end users.
  • MAY encapsulate language/framework-specific opinions, data structures, and processes.
Fork me on GitHub