Using Postman to explore and debug Dwolla's v2 API

What Postman is and why you should use it

Postman, is a powerful tool for testing calls to the Dwolla API. Whether you are new to Dwolla, want to explore the API, or are deep into your Dwolla integration debugging requests, Postman offers a simple interface to quickly consume the API. It’s my go-to app, I even use it on a daily basis when working with external developers!

One common issue I debug with developers is malformed requests. Whether it’s a mis-typed request parameter or you aren’t passing in the correct headers for the request, small issues like these can seriously delay the integration process.

With this in mind, I decided to put together a Postman collection— essentially a templated series of all requests in the API pointing towards our Sandbox environment. My hope is that you will find this collection useful in improving your development workflow efficiency. Read on for more info on getting set up with Postman and using the collection…

Setting up Postman and importing the Dwolla API v2 collection

To get started, make sure you have the Postman app downloaded. Once you’re all set up with Postman, click the button below which will prompt you to open Postman and import the collection.

Run in Postman

The collection—“Dwolla API - Sandbox”—will show up in the left-side pane. Here you’ll see folders corresponding to resources in the API.

Before you can start submitting requests you’ll need to configure a few variables within Postman, such as a the “client_id” and the “client_secret” which are used to authenticate against the API.

Configuring Collection variables

The collection is preconfigured to use collection variables that look like this: {{variableName}}. In order to get up and running with the Collection, you’ll want to set values for the client_id and client_secret collection variables.

To edit collection variables, click on “View more actions” on the collection in the left side nav. You’ll then click “Edit” which will open a tab to edit variables.

The collection will be preconfigured with initial variables. You’ll want to set values for both client_id and client_secret and click save prior to submitting any requests in the collection. (More information below :point_down: on where to obtain your client_id and client_secret)

Where do you obtain your client_id and client_secret?

The “client_id” and “client_secret” correspond with your Application “key” and “secret” which can be found within the Applications tab in your Dashboard. These client credentials will be used to generate an OAuth application access token, which is issued to the created application, via a pre-request script that runs before each request in the collection. The generated token string is then saved as the “appToken” value in your Postman environment to be used to obtain access to protected resources (e.g. Transfers, Funding Sources, Customers etc.) in the Dwolla API.

Now that you have your client credentials set, click save and you’re ready to start calling the API.

Using the collection

It is recommended to start out by calling the root of the API to fetch your accountId; this should then be updated as a collection/environment variable value. New environment variables such as transferId, masspaymentId, and customerId should then be set once these resources are created in the API.

The screenshot below shows fetching an Account’s list of funding sources. You’ll notice and inspect a few things when you select a request within the collection on the left sidebar: 1) a description of the endpoint you’re calling as well as required and optional parameters. 2) the request URL 3) the required headers and 4) a sample request body if it’s a POST request.

After clicking the blue “Send” button, you should then get a response back from the API allowing you to inspect: the response body (if applicable), response headers, and HTTP status code. Viewing sample JSON POST bodies provided in this collection will hopefully give you, as the developer, a point of reference as to what a request should look like.

Comfortable with using cURL to send requests to the API through the CLI or another language like Python? Postman contains a handy “Generate Code” button that allows to to see what the request looks like in a different language.

Questions about using Postman or have suggestions on improving the provided collection? Please don’t hesitate to reach out—we’re here to help!

6 Likes

Thanks for this - it’s been very helpful to me in trying out the Dwolla API!

One small thing I noticed you might want to change is the “List documents for a beneficial owner” API example is using a template value of VCRCustomerId instead of beneficialOwnerId in the URL.

Good catch @abe! I just reviewed and updated the collection so anyone pulling it in the future will have the correct global variable names. Let us know if you find anything else that may be confusing or wrong with the collection!

2 Likes

Hi @spencer, I have checked your Postman API. I couldn’t able to get token. I have given the username: and password for Authentication. Even though it was showing as a “error”: “invalid_client”. Can you help me with this?

And one more help, I was trying to hit documents API from my API(Slim Framework) and it returning “Badrequest”.

Hi @kordharani, Based on this error message, it sounds like you may be either a) calling the wrong environment (prod vs. sandbox). or b) you don’t have your client_credentials set properly.

Based on the way this collection was created, you shouldn’t need to set your client_id and client_secret within the individual request. This should be managed via environment variables (using the template above). We do plan on moving those environment variables to collection variables to eliminate the need to have two separate files (the collection & the variables). If you do find yourself editing the individual request to retrieve an access token. Here are a few screenshots that display what the request should look like. Note: Request URL, Authorization, and body params. (there are no headers set)


Moving this question to a separate thread since it’s not related to using this Postman collection.

Thanks for your reply @spencer. I can able to access it now. I have given wrong credentials.

As a newbie, I have some more questions related to Dwolla API? Should I put it here or new questions?

Fantastic, that sounds like a quick fix! For new questions, I’d recommend taking a look at using search in the top toolbar to see if you’re able to locate a similar thread. If not, feel free to open up a new topic in api-support

1 Like

Just some help if anyone else has trouble getting their app token, I was also receiving an ‘invalid client’ response despite having set the environment variables (client id/secret), and discovered that there is an “Initial Value” and “Current Value”. Somehow the current value is being cleared (maybe some startup process in the script?) - so check the environment variables with the “Quick peek” option in Postman to see if the current value is blank, and then update that value to proceed using Postman.

3 Likes

I am able to access sandbox APIs from postman. Just wanted to know whether I can access production apis from postman also?

In real scenario, calls will be from our server but just to validate the flow in prod, can I make few requests from postman in production env. Or you have any mechanism in place to block postman calls in prod env?

1 Like

Hi @hshah2811 – you can make calls to the Production API from Postman! We don’t block calls as long as they’re coming from a server and not the client-side.

1 Like

thanks Shreya. Just a bit clarification. What do you mean “coming from sever” and not the client-side?

Sure!

By client-side I mean the front-end of an app – anything that is virtually visible in the web-browser. Calls made to the Dwolla API from the front-end will be rejected with a CORS error. By server-side I mean the back-end of the app.

Here’s a helpful question in Stack Overflow which explains the benefits of making calls on the server-side vs the client-side.

Here’s also a blogpost that helps explain the differences between them.

I had the same understanding but wanted to double check and it make sense to have server side calling for number of reasons including security, future changes etc. Anyways, thank you for prompt response.

1 Like