I played with the Intuit AnyWhere API about a year ago and at that time, there were some reporting entities such as the balance sheet and income statement. I notice now in V2 and V3, all that has disappeared. Does anyone know if there are any plans to add it back in? Seems like a fairly large omission given the functionality of the QB SDK.
In v2, the reports are definitely still supported for QuickBooks Desktop. Docs are here:
https://developer.intuit.com/docs/0025_quickbooksapi/0050_data_services/v2/0500_quickbooks_windows/064_reports
QuickBooks Online has never supported any form of reporting.
As far as v3 goes, it's still in private beta, so everything is pretty much still up in the air on that still.
Related
Based on the Analytics Data API Banner ("Keep in mind that these APIs are pre-release and subject to change. Code built using these APIs should not be pushed to production. While we will try to notify you of upcoming changes, you should expect to encounter breaking changes before the APIs are publicly released."), the APIs are pre-release and subject to change.
https://developers.google.com/analytics/trusted-testing/analytics-data
When is the Analytics Data API expected to be out of Alpha?
When is it expected to be out of Beta?
Is this timeline a few months, a few quarters, or will it take a year or more to stabilize and publish?
Followup question, if this is going to take some time to move out of Alpha / Beta, do you expect to allow "App+Web" upgrades to downgrade back to "Universal Analytics"?
I have also sent an email to the address in the documentation with no response.
Thanks!
Brie,
I don't believe there is a public timeline on the API release cycle, but we hope to move on to Beta fairly soon. As for your second question, it is not possible to downgrade GA4 (formely App+Web) properties back to "Universal Analytics", as they are fundamentally different.
Thanks,
Ilya
The Google Analytics Team
I imagine most developers are waiting until the official release of the API before incorporating it into their workflows. But I would recommend that we all spend some time testing the API and provide feedback to Google. That way we can point out any issues and suggest features that will be of value.
For example, I want to pull up to 50+ dimensions and metrics but the API limits runReport requests to 9 dimensions and 10 metrics. I doubt Google will budge on those quotas so I figured I'd run multiple queries and merge them programmatically. Unfortunately, that's not a viable approach since there is no universal key/column available to effectively join data across those queries.
However, if the Google Analytics session id were a dimension it could serve as that universal column. So I made an entry under the Google Analytics Issue tracker requesting just that (feel free to star Issue#: 188980721).
So get involved, the sooner we do and vocalize our needs (especially at this stage of development) the more likely the API will meet those goals.
My question is related to the recommended way (going forward) to talk to on-premises Exchange mail box and perform operations on it from an external application programmatically?
EWS APIs and the corresponding SDKs look promising based on a few articles such as this :
https://blogs.msdn.microsoft.com/webdav_101/2018/06/19/about-using-ews-and-powershell/
but there is bit of confusion on whether it will continue to be supported in the future based on this:
https://blogs.technet.microsoft.com/exchange/2018/07/03/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/
Although the above talks of just o365, the fact that EWS will no longer be invested in, raises the question if new applications for on-premises exchange should continue to use it.
PowerShell, remote PowerShell etc. also might work but it seems less suited for use/integration within an external application and more so for automating operations.
Could someone please throw some light on what is recommended way going forward to work with on-prem Exchange?
Try the Microsoft GraphAPI. Details https://developer.microsoft.com/en-us/graph/graph-explorer here. Sign in. Try the https://graph.microsoft.com/v1.0/me/messages sample. See more examples by clicking "Show More samples" on the left column after you login.
Is it The Way (tm)? I don't know but is very cool. I have some sample code I'm working with, nothing in a format to share, but look like the API covers a lot of territory. Some client-only rules look like they need some work to expose, maybe they'll get beefed up in later releases.
Depends on the type of Application you are trying to write, EWS is going to be around in Exchange 2019 so it will work just fine talking to say 2013, 16 and 19 OnPrem. There are advantages and disadvantages to using EWS vs. the new REST API's but it is application specific and changing fast. But again it depends entirely on the type of Application you are trying to write and what version of Exchange you need to support. And typically newer features that will appear in new OnPrem versions aren't back-ported into older versions. So a great new feature that will work in Office365 and Exchange 2019 may not work in 2016 and you may need to use some of the older legacy API's to achieve the same thing. Bottom line as of today if you are an ISV and need broad coverage support for versions of OnPrem Exchange expect to need to use both EWS and REST. If you are just creating apps for one organization that's going to be migrating to 2019 in the future you'll probably get away with just REST.
I don't quite know if my question fits here, but I don't know who else to ask...
I recently upgraded my socialengine plugin, which should allow me login to my site via Facebook. The reason I had to upgrade it because it didn't work anymore since Facebook changed the API (API-KEY --> APP-ID). I think this was around 2010!?
Now I bought the latest version of the plugin, just to find out that it still requires an API-KEY. Their support told me that it's not supported anymore because the version of my CMS is not supported anymore (nice to find that out after paying for it). However they offered me to make the plugin work for me, if I am willing to pay, with a hint that due to the massive changes in the API it will need a lot of work.
To come to my question: Have there really been such massive changes? Has a task like logging into a site via Facebook become that different? I am coming from a programming background, may i be able to fix this myself?
The Facebook API is constantly evolving with breaking changes all the time. 2010 is a long time ago for the FB API, so it sounds likely it'll be a lot of work updating the plugin (if the required API features are even still available!)
So we are all familiar with using syntax like the below;
Intuit.Ipp.Data.Qbo.Bill for on-line
and
Intuit.Ipp.Data.Qbd.Bill for desktop
My application talks to both on-line and desktop, as I am sure most do, and I find myself coding a lot of duplicate code because of "Qbo" and "Qbd".
So my question is; do any of the available SDKs use a common "data" structure for both on-line and desktop so you don't have to code everything twice?
Thanks Much!
Freddy,
The service and SDK for v2 have separate code paths for QuickBooks Online and QuickBooks for Windows. The v3 implementation of the service and the sdk unifies both Desktop and Online, so it is less code for you to write.
If you are interested in participating in the v3 Beta you can sign up here:
http://ippblog.intuit.com/blog/2013/03/application-for-early-access-to-quickbooks-api-v3.html
regards
Jarred
do any of the available SDKs use a common "data" structure for both
on-line and desktop so you don't have to code everything twice?
Right now, no, there is no unifed API.
Intuit Anywhere v2 data service has separate APIs (as you've seen) for QuickBooks Online vs. for QuickBooks for Windows, that differ significantly in implementation.
The only other alternative (the SDK) also has two similar, but significantly different implementations.
The good news is that v3 of the Intuit Anywhere/Intuit Partner Platform data services will have a unified API. Intuit is working on that, and it should be available soon.
The documentation here and here seems to be saying that I can only filter strings with exact matches "Supported Operators for Strings :EQUALS:"
I'm using the IPP .NET Devkit so my search looks like this:
CustomerQuery qboCustomerQuery = new CustomerQuery();
qboCustomerQuery.Name = "Southwest";
List<Customer> customers = qboCustomerQuery.ExecuteQuery<Customer>(context).ToList<Customer>();
However I need to find a customer name that contains "Southwest" in it. Is my only choice really to cache the customer names locally and search my own db? This seems asinine. Please tell me I'm being an idiot and that this system isn't really this obviously broken.
Unfortunately, the Intuit Anywhere APIs really are this crappy at the moment. :-(
Here is the list of filter operations that are supported for strings:
https://ipp.developer.intuit.com/0010_Intuit_Partner_Platform/0050_Data_Services/0400_QuickBooks_Online/0100_Calling_Data_Services/0030_Retrieving_Objects#Supported_Filter_Operators
Note that the only one supported is:
:EQUALS:
Ick!
Fortunately, Intuit is hard at work on the v3 APIs. It was rumored that v3 will support better filtering.
Unfortunately, Intuit is doing their usual thing and not involving developers in the v3 dev process anymore, so we really won't know whether or not v3 is going to suck until it's actually released. sigh You'll notice the last update about v3 data services was in October by Wei... unfortunately Wei isn't even on that team at Intuit anymore, so who knows what the status is, or even if there's anyone at all working on v3 anymore at Intuit.
I had to do something similar. Sadly, as Keith pointed out, it is not yet supported. What I ended up doing with this was fall back on LINQ.
I read in all of the customers, and then filtered using LINQ. This prevented me from having to write and read from a db and speed things up by keeping the data in memory.
So, for now, try LINQ. Hopefully we will get a better solution when v3 comes out.