We’re an API-first company at Dwolla, constantly making improvements and adding new features to our API. But what about the Software Development Kits (SDKs) used to interact with it?

SDKs exist to make developers’ lives easier. They take the tedious work developers would otherwise have to do themselves and move it into shared libraries that can be used by any application. Just as Dwolla takes care of ACH for your business, SDKs take care of the API interaction for your developers so they can spend time on building or enhancing products that are a core part of your business.

Our SDKs have traditionally focused on making it easy to interact with the Dwolla API. They abstract away a lot of the grunt work of programming with the API and simplify functions like creating tokens, making requests, file uploads, etc. All without having to dig into the OAuth spec or Dwolla Developer Documentation to figure out exactly how those requests need to be made.

Working closely with developers of various levels of knowledge and experience, we noticed some areas for improvement. Two common pain points surfaced relating to managing access tokens and constructing less straight forward requests through the API. These pain points require reading documentation, writing additional code and most importantly, they leave room for error in the code. What if our SDKs took care of these tasks and let developers focus more on their applications?

Token management

Obtaining an access token is the first thing developers do before sending requests to the Dwolla API. Our SDKs provide methods for obtaining tokens, such as the one used in this example from dwolla-v2-node:

import { Client } from "dwolla-v2"

const dwolla = new Client({ key: "yourKey", secret: "yourSecret" })

  .then(token => token.get("customers"))
  .then(res => console.log(res.body))

This is simple enough; however, tokens expire after 60 minutes, requiring developers to retrieve a new token when their current token expires. Wouldn’t it be nice if the SDKs took care of this for you?

As of today, dwolla-v2-node (v3.0+) does just that by introducing request methods on the Client object itself that take care of managing tokens for you. Here’s what the previous example looks like using the new GET method:

import { Client } from "dwolla-v2"

const dwolla = new Client({ key: "yourKey", secret: "yourSecret" })

  .then(res => console.log(res.body))

Behind the scenes, there are new methods that take care of getting an access token for you. They use that token to make requests until it expires and a new token is fetched automatically. Over time we’ll be introducing similar functionality to our other SDKs.

High-level Request Methods

The best SDKs are not just simple; they’re intuitive. Developers would rather stay in the flow of their code than troubleshoot back-and-forth trying to figure out someone else’s code. Luckily, statically typed languages let us include information typically found in docs within type signatures.

Our new Kotlin/Java SDK (Preview) is the first to experiment with this. We’ve added some higher-level methods in addition to the lower-level GET, POST and DELETE methods found in our existing SDKs. These methods perform common tasks like fetching resources upon creation and bake in best practices like idempotency keys. Most importantly, their type signatures specify the parameters required for each request.

Let’s compare the low-level methods to a high-level method when it comes to creating an unverified customer.


val dwolla = Client(key = "yourKey", secret = "yourSecret")

val createCustomer: Response<String> = dwolla.post(
        "firstName" to "Dee",
        "lastName" to "Wolla",
        "email" to "developers@dwolla.com"
    Headers("idempotency-key" to "h532jk")

val getCustomer: Response<Customer> = dwolla.get(

val customer: Customer = getCustomer.body

This is a pretty simple process similar to our existing SDKs, but it’s not very intuitive. You’ll need to look up a few things in our docs such as:

  • The request URL used to create a customer
  • Parameters for creating an unverified customer
  • How to use an idempotency key
  • How to fetch the created customer

Now let’s do the same with a high-level method:


val dwolla = Client(key = "yourKey", secret = "yourSecret")

val customer: Customer = dwolla.customers.createUnverified(
    firstName = "Dee",
    lastName = "Wolla",
    email = "developers@dwolla.com",
    idempotencyKey = "h532jk"

The high-level methods abstract away the inner workings of the Dwolla API and let you focus on what’s relevant to your application. Separate methods exist for each customer type—each with their own set of parameters—giving developers the information they need to create any type of customer without leaving their IDE.

Share Your Feedback

To recap:

These are some of the first steps that we’re taking towards improving our SDKs. Any feedback would be extremely helpful as we move forward, so feel free to drop us a line on GitHub or our discussion board.

Start building in our sandbox for free, right now. Get a feel for how our API works before going live in production.


Stay Updated