I am new to QuickBooks and all my searching has been leading to conflicting answers. I really need to know this to move forward.
We have an on-premise application (legacy MFC app if that matters). Some of our customers use QuickBooks Online and we can send information up to it. In the past we have used QBXML which I believe is not supported for online anymore.
Everything I read at intuit.com talks about web applications. I think I have to have OAuth security and I do not see how intuit is supporting that from a non-browser based application.
I cannot believe that intuit would not have an answer for this situation so I must be confused.
So, can I send data to QuickBooks Online from a desktop application?
If yes, which API/SDK should I be using?
If I need OAuth how exactly do I implement this?
Does any of this require an independent security review?
I think I just need a little help getting pointed in the right direction.
Thanks
Unfortunately I think you have the most difficult scenario in the QB ecosystem.
I've used the DevDefined OAuth library with some success:
https://github.com/bittercoder/DevDefined.OAuth
You can get this to work on the desktop if you have a localhost server that the browser can redirect to on the OAuth callback.
Anything that talks to QBO needs to use the QBO API v3 now.
For a custom app that talks to QBO, you would need to set up your app # Intuit to run in development mode, so it wouldn't have to go through their security review, etc. But that limits the number of connections you can have (I think it's 10). So it might not work in your case. Also, if you're distributing your app to "normal" customers it may not be the best user experience, and probably isn't practical, to set it up so OAuth will work on the desktop.
You might just have to bite the bullet and create an intermediate web service on something like Azure or Heroku, then go through the whole process of getting Intuit to bless your app for production.
Related
basically I want to deploy a NET.Core application where Calendar data will be read from an Exchange server account.
So the user has to fill out his login data and that it.
This works fine with Exchange.Webservices in Windows, but Exchange.Webservices are not working in Linux due the .NETFramework dependency.
I also tried the "Sherlock Exchange.WebservicesStandard" package which is also not working.
Microsoft Graph is a product I don't understand.
Is is correct, that every user needs to have an Azure Account and his own APPID?
If that is correct, this product seems to be a little bit useless in my opinion.
Any ideas?
Best regards!
As a developer, you will need an appid for your application which you will get from https://portal.azure.com/. Users of your application will not need any of this.
Please see this link with Quick Starts to help you with development using Microsoft Graph https://developer.microsoft.com/en-us/graph/quick-start
I'm trying to develop an open source solution which will be deployed on Raspberry Pi's or similar SBCs. The RPi part is only relevant insofar as it means all the code and app resources need to be publicly available.
The solution needs to read Twitter statuses, as close to real time as possible, and with as little interference from third parties as possible. I found Twitter's Streaming API, which is blazingly fast, and would be perfect for my application – except it requires OAuth. And as far as I can tell, the OAuth mechanism isn't well suited for deployment on users' machines, since it relies on a secret key which belongs to the application owner (the consumer secret).
I couldn't find any easy way around this – the only solutions I could think of are either handling request signing on a central server, or asking each user to create their own Twitter app account. And I find both solutions terribly distasteful.
Do you see any elegant way out?
It turns out this is indeed not currently feasible cleanly with any of Twitter's public APIs; not now, and not in the foreseeable future. Refreshingly, for once we do have proof for a negative: I also asked this on Twitter's own forum, and I was lucky enough to have my question kindly answered by Andy Piper, Global Lead Developer Advocate at Twitter. There you go.
Your app can open a web browser with Twitter's application authentication webpage loaded. When the user enters their credentials Twitter will return a code which they can copy/paste into your app. It's not particularly elegant. Here is a Python example of the workflow: https://github.com/geduldig/TwitterAPI/blob/master/examples/oauth_test.py
I am creating iOS application that needs to interact with RESTful API (which will be going to make).
The problem is I have no knowledge in the realm and would like to ask for some helps. (I tried to learn this for few days but as I study more, I get so confused...)
My company has a server that is running with Windows. What is the process of deploying APIs there and use it as data storage as well.
My company has Microsoft 365 license so that I have access to SharePoint. I've read there is SharePoint APIs, so it will be nice to integrate with my app. But more I study about it, I've observed AzureAD. Is it something that I must to have in order to utilize MS SharePoint APIs?
I know it is very broad question but I really appreciate for anyone who provides with helps. Thank you
Yes you will need Azure AD to interact with the sharepoint api, using the oAuth authentication by registering the app into the Azure AD and giving the Sharepoint Management online permissions that are required for you to do the operations that you want.
I have an application that uses personal access token to access to GET the list of items. I want to switch to using OAuth, the application will use ITEMS_READ only.
My application is a daemon running on an instance of secure Ubuntu server dedicated to this application(s). Regarding the "application server" is there anything that square recommends - what are typical best practices with the "application server"?
Thank you
The API documentation is fairly extensive, and includes a helpful section about OAuth. A few common pitfalls I've noticed with OAuth implementations in the past lead me to call these things out:
If you are only building a one-off integration for your own use, it is probably not worth using OAuth.
Make sure you understand how OAuth works. If you find yourself asking for users' client secrets or personal access tokens, or anything else that requires them to open the app management dashboard at connect.squareup.com, you need to rethink your implementation. Only you, the developer, should need to understand access tokens and other API credentials.
You can generally ask for more OAuth scopes than the bare minimum that you need. I'd recommend getting MERCHANT_PROFILE_READ as well. That can be useful to manage accounts, and so you can hit /v1/me to get various IDs you'll need.
The Square OAuth access tokens expire as described here. They last for thirty days, so this can tend to creep up on developers who aren't aware of it. You will need to use a scheduled task to renew access tokens that are about to expire and purge your old tokens after doing so. Something as simple as a cronjob should be fine.
In terms of the technology stack you use, that's entirely up to you. The Square Connect team is happy to help and provide recommendations when we can.
I've been asked to develop some software for a friend who has a business that he manages using Quickbooks Desktop. I don't have Quickbooks Desktop, and I'm not quite sure how to get started. I've read the docs for about a week now and can't seem to figure out the first step.
From what I've read, it seems like maybe the Quickbooks application starts a web server and mine application will be issuing HTTP requests against that web server ? It would be nice if I didn't have to have the Quickbooks application to do this development; is there a way to read the data file itself ? Does it cost money to develop software that uses this API ?
It looks like I would probably like to use the V2 XML protocol for what I'm trying to do which is: retrieve checks and deposits, make a monthly summary, format that summary according to his specifications, and create a PDF of the statement.
From what I've read, it seems like maybe the Quickbooks application
starts a web server and mine application will be issuing HTTP requests
against that web server ?
That's one possible way to implement things.
If you give more detail about specifically what you're trying to do (what programming language? what version of QuickBooks?) you'll probably get better recommendations than that route.
It would be nice if I didn't have to have the Quickbooks application
to do this development; is there a way to read the data file itself ?
You will have to have QuickBooks, there's no way to read the raw datafile.
It's cheap on Amazon - buy it there.
Does it cost money to develop software that uses this API ?
There are no charges while developing, and for one-off/custom/in-house integrations like you're talking about, there are no charges at all.
It looks like I would probably like to use the V2 XML protocol for what I'm trying to do which is:
Be aware that v2 and v3 is technically only for SaaS applications (e.g. you have to be reselling this as an app, and allowing many people to connect their QuickBooks to your app).
According to Intuit, you should be using the SDK.