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
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.
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
OAuth2 Authorize step, remove client_id, state, scope, so all you are left with is the response_type code
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.
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.
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.
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.
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
Expand Globals, expand $_SET > Add Variable and call it realmId
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
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
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?
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.
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.
