The requested resource was not found


(Pcpeterchen) #1

Hi I am using the python sdk and I am trying to move funds from a customer’s checking, to a holding account, and then back to a customer’s savings account. I am having trouble verifying and unverified bank account. When I try to authorize a sandbox account I get “The requested resource was not found.” Side problem, how does one use the refresh token to make calls to the api from the python api? I always get invalid token errors.

import sys
import dwollaswagger

if len(sys.argv) < 5:
print "oauthtoken, custid, routingnumber, accountnumber, nickname"
sys.exit()

oauthToken = sys.argv[1]
dwollaswagger.configuration.access_token = oauthToken
client = dwollaswagger.ApiClient(‘https://api-uat.dwolla.com’)
funding_api = funding_api = dwollaswagger.FundingsourcesApi(client)

def makeBank(custid, routingnumber, accountnumber, nickname):
new_fs = funding_api.create_customer_funding_source(custid, body = {
“routingNumber”: routingnumber,
“accountNumber”: accountnumber,
“type”: “checking”,
“name”: nickname})
return new_fs

try:
fs = makeBank(sys.argv[2], sys.argv[3], sys.argv[4], sys.argv[5])
except:
fund_sources = funding_api.get_customer_funding_sources(sys.argv[2])
fs = str(fund_sources._embedded[‘funding-sources’][2][’_links’][‘self’][‘href’])

print fs
ret = funding_api.id(fs)

x = funding_api.micro_deposits(ret.id, body = {
“amount1”: {
“value”: “0.03”,
“currency”: “USD”
},
“amount2”: {
“value”: “0.01”,
“currency”: “USD”
}
})

print x


(Spencer Hunter) #2

@pcpeterchen, I am not seeing a step in the code provided which shows initiating micro deposits to the created funding source. Have you initiated MDs by POSTing with an empty request body? What is shown in the response when you get the funding source by id? There should be a link relation of either “initiate-micro-deposits” or “verify-micro-deposits”

You should be using an access_token when making requests to the Dwolla API and it should be passed via the Authorization header. A refresh token is paired with an access token for the purpose of generating a new access token and refresh token pair. Dwolla’s implementation of OAuth 2.0 uses short-lived access tokens and long-lived refresh tokens. When a user account grants authorization to your application, Dwolla will issue an access token which expires in 1 hour and a refresh token which expires in 60 days.


(Pcpeterchen) #3

Hi Spencer,

Thank you for replying. Is there a way to POST the MD using the python sdk? I have verified some previous bank accounts on a different customer using this same method above, but for some reason this particular bank account is not working. Do you know of test bank accounts for the Dwolla Sandbox SDK?


(Spencer Hunter) #4

Yep! You’ll just pass in the id of the bank funding source or the full link to the micro_deposits method. i.e.
fs_api = dwollaswagger.FundingsourcesApi(client)
new_fs = 'https://api-uat.dwolla.com/funding-sources/6bee8cab-a7d2-4f2b-9dfc-21211c027375
fs_api.micro_deposits(new_fs)

If successful, we should respond with a 201 and a link to https://api-uat.dwolla.com/funding-sources/6bee8cab-a7d2-4f2b-9dfc-21211c027375/micro-deposits in the location header.

For a test bank you can use the following routing number: 222222226. We do validation on the routing number so you’ll want to be sure this is real when testing in the Sandbox. Note: we check on routing number, account number, and type so you cannot add two funding sources with the same information.


(Pcpeterchen) #5

Hello Spencer,

When I try to generate an auth token with a POST, I use the following code. I get an access token with all the scopes, but when I use this token I get invalid toke errors. Is there a different way to allow out application to access user information? Currently to access the Python SDK we are using the access token generated from the application manager on the Dwolla website.

import requests
import json

url = ‘https://uat.dwolla.com/oauth/v2/token

payload = {
“client_id”: “KORB1uPLiCs2vO96B4Hiwxf8PsQ3Vk43I4k4oopegs5HjrmkLd”,
“client_secret”: “6919gTg6EcX1EK2YulRvDgWeDuMTvIFUt3krwux52e4REeP7Mq”,
“grant_type”: “client_credentials”
}

new_tok = requests.post(url, data=payload)
parsed_json = json.loads(new_tok.text)
print parsed_json


(Spencer Hunter) #6

@pcpeterchen, From your payload, it looks like you are generating an application access token. An application access token gives your created Dwolla application access to resources that belong to the app itself which includes webhook-subscriptions, webhooks, and events.

If your application wants to get access to user account information then you will want to implement our 3-legged OAuth flow into your application. Step 1: construct the initiation URL which the user will visit in order to grant permission to your application. Step 2: Once the user returns to your application via the redirect_uri, you’ll exchange the authorization code for a user account access_token and refresh_token pair. (The token generator in the .com UI generates a user account access token for the account that owns the application)

Unfortunately the python SDK doesn’t contain support for OAuth requests at this time so you’ll want to use the requests library like in your example when implementing OAuth.

Let us know if you have any follow up questions!


(Pcpeterchen) #7

Hello Spencer,

Thank you for you help. I have a follow up question. If our application creates customers, is there a way to generate an oauth token to gain access to those customer objects (i.e. creation, adding funding sources, and transfers). We do not want to create user accounts, but rather customer objects. Does the application access token not include that kind of scope?

Thank you.


(Spencer Hunter) #8

Ah, thank you for clarifying. A Dwolla account is responsible for creating/managing white label Customers, therefore the Dwolla user account will need to go through the 3-legged OAuth flow with the Dwolla app requesting the ManageCustomers permission/scope. A Dwolla user account access token with the ManageCustomers scope is used to call the API for any Customer related actions.

An application access token should only be used for accessing resources such as events, webhooks, and webhook-subscriptions.