I know I'm probably going to get a "no, you can't do that" but it doesn't seem reasonable to me.
My client uses Quickbooks Online and wants to be able to have his customers sign in to his web site and see how much they owe, and then pay their invoices with a credit card.
Obviously, the customers themselves can't be signing into Quickbooks Online. We want the web server to be able to directly access the data via the api.
I've found the api but I'm not sure if it's possible to have the webserver connecting to it and getting the data it needs.
I know this can be done with other systems. I've done it with GMail and Salesforce using OAuth2.
The biggest piece I want to load from quickbooks as well might be something unavailable as I couldn't find it in the API anywhere. When my client opens Quickbooks Online, he can send an email to any customer that will include a link to pay online by credit card. We'd like to be able to find that link and redirect the user to it. But I'm not sure if it's available via the api.
I could go with webhooks but that would require storing all that data on our webserver, and syncing it for existing data. Not to mention what happens if an update happens to fail.
You're misunderstanding how OAuth works a bit, which is what is causing the confusion here.
The person who owns the QuickBooks company logs in, not the end-user. They log in ONCE, and that gets you OAuth tokens that you can use to make server-to-server calls forever going forward.
Soooo...
I know I'm probably going to get a "no, you can't do that" but it doesn't seem reasonable to me.
You can do what you're trying to do, you're just going about it the wrong way.
Obviously, the customers themselves can't be signing into Quickbooks Online.
Correct.
We want the web server to be able to directly access the data via the api.
That's fine, and totally do-able.
I've found the api but I'm not sure if it's possible to have the webserver connecting to it and getting the data it needs.
It is do-able.
The key understanding here is that you're going to have an OAuth connection process that the person who owns QuickBooks is going to go through just once, to get you OAuth tokens.
You're then going to store those OAuth tokens server-side (e.g. in your database).
You can then use those stored OAuth tokens to make future server-to-server API calls whenever you want.
When my client opens Quickbooks Online, he can send an email to any customer that will include a link to pay online by credit card. We'd like to be able to find that link and redirect the user to it. But I'm not sure if it's available via the api.
I don't think this information is available via the API right now.
There is an API endpoint to send an email invoice, if that's helpful:
https://developer.intuit.com/docs/api/accounting/invoice
Related
I am attempting to use "v1.0/me/joinedTeams" to get all the joined teams for the currently authenticated user in my asp.net service. This works fine for external accounts that use a Microsoft identity (have a live account) but the same call returns a 400 Bad Request when I attempt to use an external account that uses a mail identity (no live account). The request is the same regardless of external account type. The token generated when authenticating as the mail identity external user looks correct when I inspect it.
I have been able to implement a workaround where I instead use the SharePoint REST service to get the groupId for the team site the user is apart of and then use the Graph call "v1.0/teams/{groupId}" to get that team. However, I need to do this for all the teams the external user has access to which slows things down quiet a bit.
I am aware of what looks like a bug in Graph when trying to make any Graph calls with any external user type, described here: https://github.com/OneDrive/onedrive-api-docs/issues/1039. I have also implemented the workaround for this issue which requires first accessing each site the user has access to by making some arbitrary call using the REST service. Then any subsequent calls using Graph should work. I do this for external accounts with a mail identity before trying to make the joinedTeams call but still run into the 400 response.
These workarounds will suffice in the short term but they increase my execution time significantly, especially when there is a large number of teams the external user is apart of. Any insight on a solution is greatly appreciated.
/me/joinedTeams is not available for personal Microsoft accounts. Se the table on this page
I need to send emails from my server, through simple REST calls, from my backend-server email address, to the email addresses registered in the system.
But there is a problem, bear with me.
The thing is a lot of the documentation I've seen so far seems to assume I want to access the clients gmail data, which I don't, I only use the client's address as a destinatary.
A lot of the examples I've seen, involve a visual promt to authorize the access to the api.
BUT WHY?
They assume I'm gonna be making apicalls from a mobile device, acting on behalf of the client, which needs a visual prompt for consent. But none of that applies to my use case.
The thing is, there is ever only gonna be one sender, "ME" (the company email designated for the backend server).
I should be able to create a secret api_key on the google console, and send that in my request headers (like freaking FIREBASE does), or use that key to generate a token which I then send to the api endpoint (like Paypal does).
I want to be able to do something like:
POST https://gmail.googleapis.com/upload/gmail/v1/users/{userId}/messages/send
Authorization: key=<key_created_on_google_console_or_token_obtained_using_said_key>
{
message stuff...
}
The api reference on google says that I need to create an authorization using OAuth credentials, which I'm then supposed to use to create a short lived token that is inserted as
"Authorization: Bearer <TOKEN>"
in my next apicalls, until it expires. But...
In the console, creating a new OAuth2.0 client ID, says I need to create an app. But I already have a proyect and an api_key (with permissions to gmail api). And that said app is gonna have to be sent for review!. What's going on?.
So..
How do I send emails, from my own-controlled email address, using REST calls.
It's all server side, no need to access any user data (not even my own), I already control the sender address, I already have created a project on google console, I already created an api_key.
OAuth seems to think I'm doing something I'm not, so what am I missing?.
Thanks.
The Bearer token is an OAuth2 access token that you get after authorizing your app to access your Gmail account. It's designed for 3rd party authorizations really (like your users allowing your app to access their Gmail) that is why it seems complex when you're accessing your own account.
Check this out https://developers.google.com/identity/protocols/oauth2
Turns out I was trying to use the wrong tool for the problem.
After looking for alternatives I found out about MailGun and SendGrid.
Tried SendGrid and it fit like a glove. Love it.
I was using Gmail+PHPMailer for this problem and thought the new api was meant to replace that, but turns out it's not.
Alexey pointed out the intended use in his answer. Actually I might end up integrating the new Gmail api more in line with it's intended use on my clients mobile devices.
It was all my missunderstanding.
Thank you for your time.
I'm creating a simple iPhone app. The basic premise is that the app will display some data (That I provide online) on the application. The data changes over time, so the app has to draw the data from online and display it. I don't have a significant programming background so I don't want to use my own server.
Thus, I thought it would be significantly easier to just put the data into some documents on a Google account and then access them programmatically via the Google Drive API. I could then update the data in my Drive account and it would get updated in the application. The key here is that I am ONLY accessing ONE account that I own MYSELF. The users' accounts are not being accessed. Therefore the goal is to never have to log in manually. It should all happen behind the scenes, aka, it should look like a server, not a google doc.
With this in mind, it doesn't make sense to show the Google Accounts sign-in page to my users as the standard OAuth2.0 tutorial shows here:https://developers.google.com/drive/quickstart-ios#step_1_enable_the_drive_api
I should be able to access my own data by somehow hardcoding in my username, password etc. Google agrees here: https://developers.google.com/drive/service-accounts#use_regular_google_accounts_as_application-owned_accounts
The above link mentions a "refresh token" that I'm supposed to save. However, I have no idea how to build and save that token, or even for that matter, where to find it.
I've gone through both the basic tutorial and the Dr. Edit Tutorial for iOS, but they both assume that the application is accessing USER accounts not application-owned accounts.
I'm not asking for someone to write the code for me (though tidbits are nice), but if you can point me to a step-by-step guide or related sample code that would help me get started that would be awesome. I'll even come back and post the code that I use!
EDIT: Since I realized that the Google Drive API wasn't something I could use for what I am trying to do, I eventually found Parse which is an awesome tool that handles all the server backend for me and is free at the basic level.
Google APIs objective-C client library doesn't support service (application-owned) accounts, because they are supposed to be used by a server-side apps, instead of clients -- you shouldn't be distributing your private key as a part of an app.
If you would like to distribute content from a service account, maybe you should write a server leg to do the authentication and pass clients credentials in a secure way for them to talk to the API on the behalf of the service account. Or, use Web publishing to make documents universally accessible without authorization and authentication if privacy is not a concern.
Let's say I am making a sign up form in which I asked user's twitter ID. How do I verify if the ID entered by user belongs to him/her? In case of verifying email we simply send a verification link which user has to click so how do I verify twitter ID? I have never used twitter before.
The only reliable and practical way to verify that twitter account X belongs to user Y this to do full on “3 legged” OAuth authentication. That being said, you may want to consider if you might be OK with just taking the user at their word on it.
Getting OAuth to work and securely storing the resulting tokens is much easier nowadays than it once was, but is still non-trivial.
Reasons to verify the twitter account, in increasing reasonableness:
You will be making enough server side requests, on behalf of multiple users, that you run up against Twitter’s API Rate Limiting. (Having multiple auth-tokens will allow for a higher API rate)
You need to automagically send tweets and/or follow accounts on the user’s behalf
N.B. do this as opt-in and be ultra clear about when/why you will be doing this, or you will face the justified fury of scorned users
Don’t verify the account if you’re looking to do these things:
You need to send tweets and/or follow accounts on the user’s behalf, and the user will be able to perform a browser based confirmation workflow for each of those actions; use Twitter’s Web Intents for this.
If you just want to pull in real time data for user’s avatar, bio, or recent Tweets Twitter supplies some prefab widgets for you.
All of the authenticated Twitter API Calls can be done client side with JavaScript. Twitter has a js framework, which does not require you to handle and store tokens on your server, to help you with that.
An alternate contact method for password resets, notifications, etc.
Private communication between users on twitter requires mutual following, many users probably never check their Direct Messages (or even know what a DM is), and any messages would be limited to 140 characters. Just use email for all that kind of nonsense.
If you’re just gathering this info to display it on a user’s profile page, in an “other places on the web” kind of way, integrating and maintaining all the server side OAuth pieces is likely too much bother. Just make sure you have a reasonable and clear TOS and an obvious way for 3rd parties to report any of your users who may be claiming a twitter account that is not their own.
If you’re still interested in OAuth, Twitter's Dev page has plenty of resources, including a nice overview of a generic “Sign In with Twitter” “3 legged” OAuth work flow.
I have a j2me project on blackberry that needs to connect to twitter. I did most of the hard stuff already, I've got an api that guided me through to the access token pretty easily. Now I can't seem to get the authentication to work with a status update in REST.
I know my tokens are valid because if I run a GET method like verify credentials, it's fine, everything is valid. But POST messages are just confusing me. Am I supposed to pass in a whole consumer key, signature, oauth version, etc every time I update a status? Or do I just pass the access token? Are they all supposed to be POST variables or just the ones specified in the twitter api as parameters. The twitter api documentation has left me completely lost.
If someone had a link to a site that had examples of all of these messages put into plain text NOT in an library as 99% of tutorials for this situation are, it would be really helpful.