We are setting up Google My Business using the following oauth instructions.
https://developers.google.com/my-business/content/notification-setup
However, there seems to be a process somewhere that keeps changing the settings and sending the notifications to a different pub/sub topic. So basically it appears to be making a PUT request to :
https://mybusiness.googleapis.com/v4/accounts/{accountId}/notifications
Is there a way to determine the source of the request ? There does not seem to be any instructions on how to access Google My Business API audit logs.
You should check who else has access to that location group, ideally through the GMB UI as that can give you an e-mail address hint:
Related
My use case requires me to integrate teams with an app. Whenever a message is sent from that app, a private channel will be created and the message will be sent to teams. I've been reading the documentation and it has only confused me further. Do I need to use graph or bot? Can I do this using only graphs or only bot?
It's possible to send a message using Graph API - see here for more: https://learn.microsoft.com/en-us/graph/api/chatmessage-post?view=graph-rest-1.0&tabs=http
HOWEVER, there are two ways to authenticate with Graph, either via an "application" permission (kind of like background service), or via "delegation", which means your app would work on behalf of a user. For this specific Graph endpoint, Microsoft mentions in the page that Application permissions are only allowed for "migration" (e.g. if you were building a tool to migrate from, say, slack to Teams). That means that you would have to use "delegation" which means the message would appear to come from a specific user.
As an example, instead of the message coming from "ABC Application", it would appear to come from "Syed Muhammad Ibrahim". If that's ok, then you can use Graph. If not, you would need to go the Bot route.
I have integrated twilio and it was working fine but suddenly
end users stop receiving top message at their mobile. Is there any capacity problem if yes then how to fix this
Without providing the code, I can give the following suggestions to check upon.
1. Check if the Twilio Account has enough balance to send messages
you can check this in the dashboard.
2. Check if the Message template used is verified or not.
If the template is rejected for some reason, you won't be able to use it.
3. Use the API Gateway Dashboard to determine the cause for no sending messages.
If you can see the messaged being in outbounds mode, but not being sent, you can check the reason for it.
4. Check if the Twilio API library used has changed the API structure
Refer to Twilio Docs and confirm if the APIs have received some changes in them, deprecating any changes. (This is very rare, as most API Providers keep the Legacy API code format active for some time for users to migrate from it.)
5. Confirm If any New Government Rules are changed.
Ex. In India, there are some new laws put up for sending SMSes to users. You would need to follow the rules to register the template again to a Mobile Carrier's site, and then use it. These details will be provided on Twilio Dashboard.
I cannot find a good working sample that calls the Graph API and retrieves the user's contacts from within an Azure Function. Part of the issue is a lack of documentation and samples as this seems new-ish. Is this even possible? I am trying to create a function that can take a phone number and check against the user's contacts to see if the contact exists. So far, the only way I can achieve authentication is to use Postman to retrieve a token manually. That token didn't even work to retrieve the contacts. I know I am doing something wrong but I think what I really need is the big picture. I'm missing something. Thank you for your help.
The auth token binding may help at least with the act of getting the token. In this case, if it's on behalf of the user invoking the function, you'll want to use the identity: userFromRequest setup. Keep in mind that for debugging, you'd still have to acquire a user token for the app and attach that to calls to your function, but you can use the function app's /.auth/login/aad and /.auth/me endpoints for that.
Make sure that your application registration has the Contacts.Read permission. This is required for the contacts API.Today, the UX for App Service Authentication / Authorization today links to the existing permissions UX, which unfortunately uses different names for things. I'd recommend navigating directly to the AAD section of the portal and selecting App registrations (Preview). Find your app registration there (defaults to same as your app name), and browse through the API permissions there. That way the right names show up and will match the Graph docs.
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
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.