Query Quickbooks API

Has anyone connected to the Quickbooks API? I’m having a little trouble with the query formatting.

So far I have the Oauth2 Provider and Authorize steps set up. I’m able to click a button, which navigates me to Quickbooks where I can login and be redirected back to my app. I think the access tokens are being saved by Wappler (can someone confirm Wappler handles this when using Session Token Handling?)

I’m now getting hung up on the actual API Action to query data. At this point, I’m just trying to return company info using the Quickbooks sandbox company.

Here’s the sample request URL from the quickbooks docs:

GET /v3/company/123146228950379/query?query=select * from CompanyInfo&minorversion=51

Content type:text/plain
Production Base URL:https://quickbooks.api.intuit.com
Sandbox Base URL:https://sandbox-quickbooks.api.intuit.com

And here’s my API Action:

This question is likely specific to quickbooks, but can anyone tell what needs be in the query and headers fields? A 404 Not Found error is returned from Quickbooks.

are you able to pull the schema?
I mean as far as the authorization looks to be dynamic? Bearer {{ etc. what happens if you just put the authorization info in there as is and try to pull the schema? And once you have that change over to the dynamic authorization?

also have you tried the API on something like Postman? A lot of times I’m able to trouble shoot the API there to make sure I’m sending and receiving the data the way I think I should and then once you know thats correct it helps to troubleshoot the way Wappler implements the API’s as they are all a little different.

Keeping your api action with all the same options just change the date type from JSON to Auto please and try again.
Can you let me know if it changes anything at all in the response from Quickbooks.

@psweb No change when using Auto

Just looking at the quickbooks docs a moment and will try let you know

@baub good idea. I can use the Run operation to pull int he response schema, but can’t get the Fetch Schema to fetch. I’ll keep working on that.

I receive this message when trying to fetch the schema:

"Error code 3202, message = invalidFieldFormat; statusCode = 400, Detail: Authorization type is unknown. Type identified: Bearer "

This error comes up when pasting the auth code directly in the Header and when proceeding it with Bearer

Could i see your oauth2 provider step, you can blank out your secrets and keys, want to see your scopes, endpoints, params, etc.
Also if i can see your Authorise step, again blank out sensitive data if any

image

Nothing sensitive here - these are dev keys to a Quickbooks Sandbox company.

1 Like

Also here’s what I get from the authorize response:

1 Like

Ok, I think I got this working

  1. OAuth2 Provider step, perfect as you have it.
  2. OAuth2 Authorize step, remove client_id, state, scope, so all you are left with is the response_type code
  3. API Action
    Url: https://sandbox-quickbooks.api.intuit.com/v3/company/123146228950379/query
    Data Type: Auto
    Query Parameters
    • query select * from CompanyInfo
    • minorversion 51
      Authorization is fine as is

Basically you almost had it, the problem is that the query parameters are anything after the ? and & in the URL, the company is not a parameter but forms part of the URL.

Mine


Screenshot 2020-06-03 at 01.26.52

When I click Open In Browser
Opens the company selector
choose my sandbox, click next
response (ignore the first line of test: testing)

In the intuit developer area for Keys & OAuth I have added a redirect URL of the actual script https://www.example.com/dmxConnect/api/qbtestapi.php
As well as App URLs
Host Domain: example.com
Launch URL: https://www.example.com/dmxConnect/api/qbtestapi.php
Disconnect URL: https://www.example.com/dmxConnect/api/qbtestapi.php

Although these are wrong for real life, for testing purposes it wored fine.

It’s working! Thanks a ton. This is great.

The company id (i.e. realmid) will be different for each user on the system, so that URL needs to be dynamic. Would you recommend saving that to the database in the Authorization step?

Yeah, that company chooser seemed pretty strange to me anyway, I created 2 sandbox companies by mistake when setting up, and although my realmid was hard set for company 2 I was still able to get companyinfo for company 1 or 2.

You can store and use dynamic parameters directly in the URL part, so I agree with your idea to rather store the realm in a database for now, rather have it and not need it.

Just tested, I was wrong, so my API is hard set for company 2, in the account chooser when running the API if I choose company 1 or company 2, the info always returns company 2.

In my mind, I would assume the company chooser should set the realm id dynamically, just going to check this, maybe we need an API action before to get the company listing and then dynamically select the company.

Ok figured out the realmId problem.

So you have the OAuth2 Provider run, then the OAuth2 Authorize steps. At this point intuit starts redirecting URLs to things like the application authorization page, then the company chooser page, the company chooser is what gives the realmId and it passes this back in the actual URL redirect, so the URL looks something like.

/dmxConnect/api/qbtestapi.php?code=AB11591192256vsYnAP249Dsrz9V3chheF9LT9wKon7tiNZkWZ&state=edca3fded06e4b14617da1507fa0f86b2ab583a13cc7757d41b1291e5fabcb82&realmId=4620816365064526700

We need to get the realmId out of the URL parameter to use inside our API Action step.

To do this we first need to tell the script we are looking for this parameter

  1. Expand Globals, expand $_SET > Add Variable and call it realmId
  2. In you API Action, in the URL replce your current 123146228950379 portion and change it to {{$_GET.realmId}}
    This will make your final URL look like https://sandbox-quickbooks.api.intuit.com/v3/company/{{$_GET.realmId}}/query

Here is a screenshot of my final server action.

This way no matter what company is chosen it is the same as what is used in the API Action return.

But Wait, thats not all, lol, we unfortunately have to ask @patrick for some advice here, when naming a $_GET variable realmId which is what the API Provider has dictated and we have no control over, Wappler is renaming it realmid dropping the capital I which means we never get the parameter.

For now to fix it, right click your server action file, and select open in editor, then do a find for realmid all lowercase and replace with realmId with the capitalized I, save and close the file, refresh your server action list and test in browser.
This is what I get

Glad to see we can grab the realmId during the action step, and not have to save it for each user.

What are you using to see all of the outputs in your browser like that?

By using the Open In Browser on the action file itself, making sure every step has its out put set to on, and on steps that do not offer an output checkbox, using the output switch at the top near the save button.

Actually it looks like the realmId only comes back during authorization, and not when just using the provider step. If that’s the case, we probably want to GET and saved realmId during authorization, but not duplicate the Authorization in every Action file, right?

I would save the realmId as a session variable.

At the start of every users journey they will have to do the initial authorize which can get the realmId and add it to a session variable.
As they continue using the app, and another server action runs, the second server action will only need the LINKED OAuth2 Provider and the API Action itself, without the Authorize step at all.

Like this

So only one action needs a provider, authorize, api action.
All other actions that already have the auth token use just the steps of provider, api action.

If you save the GET parameter as a session then it should be ok.

@psweb any idea why I can’t see the session realmId here?

image

Actually, the API action is working using the retrieved realmId in the session variable, I just can’t check the value.