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.
Related
I'm developing a system which, when submitting a form through Google Forms, a script will take the data from the sheet which the data is submitted to and then set up a project in a project management software (Zoho projects), and also create Google folder structures based on the information provided.
In other words, a google form is the one location from which all project infrastructure will be created in their corresponding locations and software.
In order for this system to work properly, I need every user who has access to the form to be able to perform the same actions on every software which the script is tied to, regardless of their permissions level for each.
This necessitates the script using only one set of credentials for the 3rd party API which is authorized at a high level, and having all users of the form access only those credentials in order to get the consistent results that are needed.
The problem with this is that I cannot (or at least I don't think I can,) use the OAuth2.0 library for GAS, as user authentication would be to access only the data which the user operating the software has; this would produce many errors in the code because utilizing credentials of different authority levels while attempting to perform the same tasks which require high levels of authority would yield many errors, and lead to inconsistent functionality with the script. On top of this, because I'm referencing a 3rd party API, there's no "Service Account" that I can use to act on behalf of highly authorized users.
To resolve this issue, I've built my own wrapper library for this API in Google Apps Script and built my own authentication system in which user credentials are automatically renewed and managed using the PropertiesService capabilities. I have established access to a highly-authorized user's data through this system. I access this data in my script instead of authenticating with the OAuth2 library for Google Apps Script in order to allow consistent results from the software.
I've found my own method that works for this scenario, but after all the work I've went through, am wondering if I have reinvented the wheel. Is there any other more established way to have multiple users interface with one set of credentials of a 3rd party API through Google Apps Script? Or is this a unique situation that required the solution that I came up with?
Thanks in advance!
You could instead use GAS to create webapp that runs as you every time, and then passes ownership of the related zoho and google drive files to the user after the script runs.
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.
I am making a .NET application that will allow potential users to upload invoices they make on my app to their quickbooks account that they have set up and synchronized with their QBD version.
what steps will they/I need to take so that when they use my app, it will upload invoices to their account? Is it:
a) when they set up their account with the Intuit AppCenter, they will pick my app from the app center services (in doing so, it will generate a set of oAuth connection parameters for me to put into my app to push invoices to their account, if so how will I get these)?
b) Will I set up an account via the Intuit Platform Partners, and ask the user to use my account ID and Password by which they will "create new app" under my account for the purposes of generating oAuth connection information for my app to use?
c) Something different from the a) and b)?
Thanks!
The OAuth stuff is specifically designed to allow end-users to push a set of OAuth tokens/credentials from QuickBooks to your app. You then store the OAuth tokens, and use those to communicate with QuickBooks.
This is an accurate description of what happens, yes:
a) when they set up their account with the Intuit AppCenter, they will
pick my app from the app center services (in doing so, it will
generate a set of oAuth connection parameters for me to put into my
app to push invoices to their account, ...
You can read more about that process in the docs:
https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0011_from_the_intuit_app_center
The other scenario is that, if you allow it, the user may choose to connect to QuickBooks from within your app. In this case, they'll click the "Connect to QuickBooks" button (see the docs here: https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0020_connect/0010_from_within_your_app) which forwards them to Intuit's site, generates the OAuth tokens, and then sends them back to your site with the OAuth tokens.
In either case, the OAuth tokens will be sent to you so that you can store them and use them to communicate with the QuickBooks APIs.
This:
... and ask
the user to use my account ID and Password by which they will "create
new app" under my account for the purposes of generating oAuth
connection information for my app to use?
Is absolutely not what you want them to do. The whole point of OAuth is that you don't need to share any usernames/passwords of any time with any one.
Here are some additional answers to your other comments:
The part I am trying to figure out is what my customers will need to
do to be able to benefit from my app and its QuickBooks Integration
functionality.
They will need to log in to their Intuit.com account, and follow the prompts to connect their QuickBooks company to your app (i.e. follow the prompts to forward the OAuth credentials to your app).
Sounds like he/she will need to set up some account with ID and
password.
If they don't already have an Intuit.com account, they will be prompted to create one during the OAuth process. In the case of QuickBooks Online, they will ALWAYS already have an Intuit.com account (it's the same thing they use to log in to QuickBooks Online).
Now it seems to me that there are two ways that the customer can set
up accounts with Intuit.
They can set up an account through AppCenter, or within QuickBooks desktop directly (when you install the software, it prompts you) or if you're using any Intuit service already (e.g. QuickBooks Online) then you use your existing QuickBooks Online account.
Developer.Intuit.com accounts are only for developers (e.g. for YOU). Your end-users will not have a developer.intuit.com account. Nor do they need one.
a) what are the differences between the two?
Developer.Intuit.com accounts are only for developers. Your end-user will never see the developer.intuit.com website, nor will they see the option to "Create an App".
b) which should be used if the customer wants to set up syncing their
QBD? c)Which should be used if the customer wants to use my .net App.
d)Which should the customer use if they want both (b) and (c)? e) If
the customer creates an account the 2nd way, won't they get confused
by all the "developer" lingo?
None of those questions are applicable - end-users will never see or be prompted about any of the developer stuff. The only reason you see that is because you're registered as a developer. Normal end-users will not be, and thus won't have any of these options.
f)What if the customer has already synced their QBD with intuit?
Then they can just log in to their existing account to get connected (i.e. to send the OAuth credentials over to your app).
With regards to your questions:
A developer can choose to get his app listed on the appcenter or not depending on mkting requirements.
To understand the difference in the process- you can create a sample and then on developer.intuit.com, go to My Apps-> manage my app-> select your app. Then test connections.
You can use any of the above to use QBD data. Please see the additional info too that I have provided.
Also go through the link which consolibyte has mentioned.
If you are logging in from appcenter app, then since you are already logged in, then only OAUTH will be required.
In logging from within your app, you do not need to provide your user Id and password. The user needs to register for the first time with Intuit.com and then OAUTH process follows for him. These open id/email details can be saved in your db so that user need to enter them a next time.
The customer is never about the details of the developer except for the app which will access their company data.
The sync manager for QBD
OAUTH authorizes your app to connect to their company files.
Any of the above can be used to access QBD data.
The sync manager runs manually or automatically. So, customer can choose to sync/not sync his data.
---------------Addtional info----------
There are two ways to integrate with QuickBooks, the first is with REST APIs and the second is with the downloadable QBXML SDK v12. The REST APIs and that integration model is for applications that are to be sold to customers via our Appcenter. They are generally Saas applications.
The second model is the QBXML sdk which is available for anyone to use, especially for custom integrations.
The reference for the QBXML SDK is here
http://member.developer.intuit.com/qbSDK-current/Common/newOSR/index.html
Please go through:
https://developer.intuit.com/docs/0025_quickbooksapi/0055_devkits ->QBXML SDK
Lastly through the QBXML SDK you can add a custom field to any entity you want. See the reference above and take a look at DataExt Add Request. and once added Query Request. I believe this will give you what you are looking for.
Keep in mind this is for QuickBooks for Windows not QuickBooks Online.
You can go through FAQ page too-
https://developer.intuit.com/docs/0025_quickbooksapi/0058_faq
I am settled at this point from what Consolibyte has shared and what I have learned also. The whole picture (for me at least) is that both the Developer Account AND the App Center Account is needed. The Developer account provides the consumer key, consumer secret and application token that the .Net app will use to authenticate with Intuit. The App Center Account is needed to allow the user to sync their QuickBooks Desktop data to a location where the app center (and other 3rd party apps) can have access to it (after user authorizes of course), and to give it's user an ID and Password needed to authorize the .net app ( or any app for that matter) to access his/her Intuit data. It is the combination of the Developer Account's tokens and the App center Account's ID and password that allow the generation of an authentication/access token by which the .Net app can instantiate a Dataservices object so it can read/write to the user's instance of QB data in the App Center. Apart from the user creating an account in the App Center and synching their QB Desktop data with it, There should be little or nothing else to do except provide the ID and password, providing the .Net app is coded right. I am not talking about OpenID in this case, but do know that it uses the same ID and password.
...so I'm good. Thx.
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.