I am using the classic API. Everything works fine in the test environment and now I want to go live but all the information I see on the PayPal developer about going live doesn't discuss how to do this with the classic API.
I am not sure which API or API's you are specifically trying to use but as long as you have a live account that is already enabled for the services you are going to be using, you just need to replace your credentials. You will need to replace the sandbox credentials with your live ones, and change the environment/endpoint to the the live site. If you dont already have an account set up on live, you will need to sign up for the account. Depending on what service you are trying to use, you may have to wait for an approval before you can use it.
Related
I’ve built a google action that talks to my bespoke web Api.
The actions code currently has personal details hard coded into it. I need to make it so that when someone uses it for the first time it asks them for a username password and URL.
Is there a way to do this? Or maybe there is a way for a user to add those details to there google account in some way that the action can read them.
Alternatively is there a way to publish an action so only specific users can access it?
In general, asking for a username and password is a bad approach for Actions, for several reasons, and asking for a URL can be quite a mess. Particularly if you're expecting the user to access the Action via voice or a device that doesn't support a keyboard.
The better approach is to use Account Linking to connect their Google Account to an account they have created on your system. If you need additional one-time configuration information, you can have them provide this information for their account via a webapp, store it in a datastore of some sort, and then access it when they contact your webhook via the Action.
There is no way to have the Assistant enforce access to a production Action. You can publish an Alpha release to up to 20 accounts, but this is still treated as a "test" version.
How smartsheet developer tool account is different from paid account.
Also how developer account can be use for API call as pre-production environment.
Developer Tools can be enabled on any Smartsheet account. Having the Developer Tools enabled allows you to create an app for implementing the OAuth flow.
The purpose behind having a separate Developer account is to ensure you can experiment with the Smartsheet API without worry of making changes to critical items needed for every day work.
Since the Developer account is signed up with a different email address than the one you use for your main Smartsheet account it is a completely separate environment. But, it still acts like any other Smartsheet account. Without sharing the account to items in Smartsheet it won't be able to access them. This way you can create Sheets, Reports, and Dashboards to simulate the data you will be working with. Then as you make API calls to them you know you aren't causing issues for the real items people at your company are working on in Smartsheet.
One approach would be to share the Developer account to a collection of things you will eventually be running your requests against in production from your main Smartsheet account. Then in the Developer account make copies of those items. Once this is done you can un-share the Developer account so that it no longer has access to the real items in Smartsheet. Then you can make requests to the API to test your code and see the results as it would really happen. Once you've proven your code works you can adjust the access tokens and id numbers of Smartsheet items to work for your production stuff.
Trying to setup a bunch of logic apps with supporting Azure functions etc. concept is to utilize ML/Azure functions/Logic apps etc. to setup an automated mailing system.
Everything is deployed using ADO/Git with CD/CI pipelines, but we have a problem with the Office365 connector that needs authorisation after creation. For now, we have followed this article that creates a windows form for authentication.
This works fine, but we want to do this at scale and thus are looking for a silent approach, any ideas or links would be appreciated?
PS. Use does not require MFA
At the moment, the Office365 API authorisation works with the OAuth 2.0 Authorisation Code Grant Type, which means, you can only get the authorisation code by getting the user owning the mailbox (or having access to the shared mailbox) to sign in to get the code. This behaviour of the API is by design. Thus, there is no way to fully automate this.
If you don't need different accounts for different Logic Apps, you can create those API connections with PowerShell (still requiring the user to login in) for each environment and then use the already provisioned API in our CD pipeline.
Today I have been trying to implement the rest API into my application to look up transaction information from a transaction ID (GET /v1/payments/sale/)
I have implemented everything correctly on my end and set the mode to "live" and I can't seem to get details from a transaction.
Here is the full error code:
{"name":"REQUIRED_SCOPE_MISSING","message":"Access token does not have required scope","information_link":"https://developer.paypal.com/webapps/developer/docs/api/#REQUIRED_SCOPE_MISSING"}
And here is documentation on what I am trying to do: https://developer.paypal.com/docs/api/#look-up-a-sale
Any help would be appreciated.
Thanks.
There are few things you could do to make sure your configurations are set right.
If the mode is set to live, are you using the live credentials instead of sandbox. You can select the sandbox app and copy the live credentials from there. See bottom part of this image.
Make sure Payments are enabled on live. PayPal has a dashboard page, where you could see all the services that you have enabled to work with Live environment. This prevents accidents on unknowingly using an API on live. You can check the status here
Is the sale that you are looking for created by the same clientId that you are using for making a GET call ? Only the app who creates the sale, can view the sale.
In the mean time, PayPal has created SDKs for many languages to support REST APIs. They are actively developed, and maintained, and could help you mitigate issues in handling tokens, credentials, etc, and allows you to quickly use APIs faster and in a way that could be upgraded easily. Also, few SDKs come packaged with Sample codes, and wiki documentations. Few are still under development, but you can feel free to contribute back to these open source SDKs.
When I had this issue, the problem was that I was making REST requests using the Identity API token. Basically, I was logging users into my website with Paypal then using that token for REST requests when another token from the REST API service should have been used. "
Here is the support ticket from Paypal SDK deveoper Randy who helped answer my question even though I do not use the SDK. Thanks Randy:
https://github.com/paypal/PayPal-PHP-SDK/issues/785#issuecomment-282749095
I seem to be having a weird problem with my personal account getting mixed up with my work account when using the GA API... I created a dev con project under my work account and downloaded the client secret json file, but, even though I have never used any Google API with my personal account, the GA API seems to be only picking up my personal site...
Oddly, when I use the Query Explorer, https://go-dev-tools.appspot.com/explorer, with the very same work account, I see the correct work GA sites...
I have used the "linked" account before however but I'm quite sure that I was not on my personal account when I created my dev con client secret json Oauth2 stuff...
Has anyone run into this before? How can I unlink my personal account as I need to pull using only my work account?
Thanks for any help you can give...
Frank
First of all check that your home email does not have user access to the work accounts. It would show up even with only Read access.
Second I'm thinking perhaps you are confusing the Google API console user with the GA authenticated user.
You can create a Google API project with the GA API with your home account, with the OAuth2 and client secret etc.
It is then possible for any user to autheticate with your app (including your work email), it just uses your Google API project to get there.
If you want to keep it all seperate, then try creating the Google API project with your work email instead.
The Google API project was set up correctly, but the authenticated user, which I cached awhile ago, must have been my personal one. I nuked the cache and created a new one with the correct account and seems to be fine.