Firstly I know you can get an API key, they rejected my application due to not spending enough with them in the past.
What would be the best way to login each day and grab a report? The days stats.
Im thinking Ruby using Selenium Web Browser Automation with some jitter of the time that grabs the report as they would be quite smart about detecting bots etc
Has anyone done this and is there a better way other than getting an API key?
You can schedule reports from the AdWords user interface without messing about in the API at all - see this link for instructions:
https://support.google.com/adwords/answer/2404176?hl=en
It's easy enough to set up & they will email you a link to your report each day.
If you need to automate some processing of the report then you could maybe set up a specific email account with reporting access then rig something up to follow the link in the email each day? Probably just as easy as going through the API approval & authorisation process and surely MUCH easier than trying to create some sort of bot to interact with the browser interface in some way!
Related
I'm developing a Mac app that uses CloudKit as its back-end. Some of my users are requesting the ability to ingest and extract data via an automation/integration service such as Zapier. For this, I need to introduce a web API.
I am planning to use CloudKit Web Services to access the app's data. This data is user-specific and hence, resides in a private database. As a result, CloudKit requires user authentication as described here.
Essentially the user needs to be redirected to an Apple-hosted authentication page. After successful authentication, an authentication token is provided that can be used for data operations. Similar to how OAuth2 works, but different enough to not work with Zapier's (or probably any other similar services) supported authentication schemes.
Who has done something similar? What are my options? I want to keep things as simple as possible and make my web API's implementation as thin as possible.
Thanks.
Niels
This is definitely doable and you are on-track with your thinking. Here's how I envision it working:
You could do all of this with a front-end web app (no server-side app needed). I personally prefer Vue.js but you probably have something in mind already.
Your app will need to authenticate the user to CloudKit using the flow you mentioned. I highly recommend you use the Web Services API and not try to wrestle Apple's neglected CloudKit JS API. For this, you are going to need to generate an API token in the CloudKit Dashboard.
You app would then prompt the user to authenticate to Zapier.
You should now have user credentials for both CloudKit and Zapier in place in the user's browser cache (you can save, for example, the CloudKit token to sessionStorage and likewise with Zapier).
Make API calls to Zapier, pull down the data, and then save it to CloudKit all within your JS app. It's all API transactions at this point. I'm a fan of Axios for making the HTTP requests.
If you are downloading files, transacting huge amounts of data, or doing processor-intensive stuff, you might consider using a server for that work. But if you just need a place to pull and push reasonable chunks of data, I see no reason why you can't do it all in a front-end app.
Alternatively, if you don't want a web app at all, and want to only have the user work in the Mac app, that can be done, too. Just make API calls directly to Zapier from within your Cocoa app. Whether or not this is feasible depends some on how you want it to work.
If you have more specific questions or need help with any of the implementation details, feel free to add a follow-up comment or ask a new question.
Good luck!
I think the other answer is mostly correct. I don't know much about CloudKit, but we can talk through what you'd need for it to work.
Let's say you had a simple iOS app that stored contacts. On the iOS side, Apple presumably abstracts the upload and download operations.
If you wanted to make a web viewer for synced contacts using CloudKit, you'd need an endpoint to fetch all rows belonging to the authenticated user (each of which would have a UUID, name, and a phone number). I believe that's possible with CloudKit code Apple provides (but let me know if I'm off base).
Now, we want to integrate with Zapier. Say, a "New Contact" trigger. You make some sort of authenticated HTTP request from Zapier to Apple on behalf of an authenticated user. It gives back a list of contacts and Zapier can trigger on the ones it hasn't seen before. To do that, Zapier needs some sort of user token.
That's where the little front-end page the other answerer mentioned comes into play. If you've got a web page that can surface a user's token to them, they can paste it into Zapier and all of the above becomes possible. I'm not sure what the lifespan of the token is, but hopefully it can be automatically refreshed as needed (rather than the user needing to take any manual action).
I'm not sure if what I've described is possible, but do let me know if it is. It would be huge if it were possible to integrate Zapier and the iOS ecosystem!
Edit to respond to comments:
Zapier won't be able to interact with CloudKit in a way sufficient for me (some minor business logic is needed)
I'm not sure what that entails for you, but it's common to put logic in the Zapier integration to structure data in a way Zapier expects. There's a full Node.js execution environment, so the sky's the limit here.
I don't think Zapier can authenticate against CloudKit as it uses a non-standard authentication scheme
Once you've got a user's token (described above, which is unusual), you will almost certainly be able to use it in requests to cloudkit. Zapier provides a "custom" authentication scheme which lets you do basically anything you want. So unless Apple uses something that fetch can't handle (unlikely), it should be fine (once you get the token).
I would like to push data directly from my app into Zapier and have it done whatever magic the user has configured
This is also probably possible. Zapier ingests data in two ways:
polling, where Zapier frequently makes a web request, store the IDs of items we've seen before, and act on the new ones. You can read more about that here. Assuming you can work your business logic into the integration, this is doesn't require an external server besides Apple's
webhooks, where Zapier registers a subscription with you and you send new data, on demand, to that address. This would probably require a webserver on your end to handle. It's optional though - you can do polling instead.
Hopefully this cleared it up a bit. Feel free to reach out to partners#zapier.com and reference this question to talk more about it.
I wondered if anyone is aware of anyway that I may modify the communication settings of multiple Twitter accounts. Basically I have a number of accounts which all currently receive info at twitter emails etc and I'd like to manage these communication settings in an automated fashion but this doesn't seem to be possible.
I wondered if there is any way to do this in an automated fashion?
I'm using LinqToTwitter http://linqtotwitter.codeplex.com/ project to talk to the Twitter API in C#, although I don't necessarily have to use this.
I'm currently starting to think of using Selenium to do this.
Does anyone have any thoughts.
Many thanks,
Andy
There are some application settings you can manage through the API. In LINQ to Twitter they're mostly available by querying on the Application entity. However, there aren't any email preference setting options that the Twitter API offers.
My experience is that these settings options tend to change over time, mostly additive. So, whatever you come up with, you'll probably need to revisit your implementation occasionally to adapt to these changes.
I'm trying to create a redistributable web application that will integrate with Google Analytics through the Google Reporting API. Customer will install the application on their server.
I'm following this tutorial (I'm using PHP, but I believe this is not of importance for my question)
https://developers.google.com/analytics/resources/tutorials/hello-analytics-api
This works fine. No issues there.
However I can't figure out one missing element:
The tutorial starts with sending me to the Google APIs console where I have to create and configure a new API project and create and configure a client ID.
That's a lot of work that requires fairly technical knowledge (redirect url, selecting correct API, error-prone copy-and-pasting, etc.)
So my questions:
Is there an API so I can programmatically set this up for my user?
If that's not possible, is there a more user-friendly way to obtain Analytics reporting that is future-proof? (I noticed they are currently deprecating a few older APIs)
Unfortunately that's AFAIK not possible.
You could go one of the following ways:
Move client_id and client_secret to some configuration file and help your customer with deployment.
Show a one-time setup wizard for your app and guide your customer step-by-step. There you can at least provide him with the right callback URLs.
Regard your application as "installed application" and instrument curl or something similar for sending the requests.
I'm building a standalone couchdb application. These are called couchapps. The idea is that the database itself is served on port 80 and returns HTML and works as the actual website. This is a very powerful idea and I'm entirely amazed by this new concept of having your code live inside your database.
But I'm having some issues with user registration. The one built into couchdb allows for cookies to be set and makes it really easy to plug it into your website. But there's several quite important things missing that my app requires in order to say that it has a "proper" user registration system.
There's no signup verification. No email is sent, no captcha is displayed. This means that anyone could spam your _users database and create as many new users as they please.
If a user forgets their password there's no facility to help them recover it.
Any idea how I could overcome these issues without doing any hardcore Erlang development at a lower level (not an Erlang guy)? It would also be great if anybody knew if I could be using OAuth to authenticate against Twitter or GitHub accounts and have that integrate seemlessly with how couchdb data is handled (inside validate_doc_update functions).
Thank you
While the built in user database can work, I would not recommend it for the workflow you describe. Here are some other options:
Browser ID
I would really recommend using BrowserID. IrisCouch has provided a plugin to couchdb here:
https://github.com/iriscouch/browserid_couchdb
This will take care of the normal registration workflow.
If you want to take it a step further and have your users "Fairly Anonymous", you can follow the example of this couchapp called "Mingle"
https://github.com/thedod/Mingle
Twitter Integration
Max Ogden's "DataCouch" project has a log in via twitter, although it is using some Node external processors to make it work. See here:
https://github.com/maxogden/datacouch/blob/master/processors/auth/twitterauth.js
Facebook integration
https://github.com/ocastalabs/CouchDB-Facebook-Authentication
OpenID
https://github.com/mcaprari/couchdb-openid
I dont think you can use the oauth purely with Couch, as this post suggests:
http://bennolan.com/2011/01/11/couchdb-oath.html
so the closest you will get there is following what Datacouch has done.
Hope these suggestions help.
I am trying to develop a very basic console application that will retrieve a user's homepage (twitter updates from people followed by the user) and save it (json). I've read a lot on the internet, but still am unsure of whether i need to 'register' such an application, and if yes, how could I possibly do it for a console app.
I'd like to get a step-by-step rundown on how I should proceed with the development. Its just a tad complex for a noob like me in this field. I'm aware that off-the-shelf libraries for doing this job are aplenty, but I lack a general understanding of how I should approach this.
Much appreciated,
Abhi
The answer really depends on a few things.
If your application is not going to try to access information about protected users (users can opt to be protected so their information and tweets are kept private) your application will not need to be authorized by any user and will not need to be registered or deal with OAuth. Without using OAuth, you will be limited to making 150 requests per hour, per IP address.
If your application needs to make more than 150 requests an hour, or needs to access protected user information, then you will need to register your application and make requests on behalf of a user. This user could be your twitter account. This will give you up to 300 requests per hour per authorized user.
I can't give you much detail as to how to best write a console application with TweetSharp., but I am familiar with Twitterizer (I wrote it).