Is it safe to retrieve credentials such as clientId, secret, etc. from an API? - api

I'm currently running an online community, we're now launching another community and actually intend to launch several over the course of the next months. Each community has their own auth0 client, as well as other settings such as, which features are activated per community, what are their Twitter/FB accounts, which API should it connect to, etc.
Right now this is still hardcoded, now I'm thinking to retrieve this all via API but I'm not sure how safe this to retrieve these all from the client? Ultimately these things end up in the client anyway via the node environment variables, so it shouldn't make a difference, should it?

Related

Bloomberg API Login without using Bloomberg Anywhere

As you may know the BLPAPI core developer guide (https://data.bloomberglp.com/professional/sites/10/2017/03/BLPAPI-Core-Developer-Guide.pdf) is not very intuitive and I was not able find a way to connect and authenticate without using the Bloomberg Anywhere Application.
I'm currently looking to develop an application that will run automatically on its own everyday at a specific time and would like to have this application to authenticate itself with Bloomberg and connect to the API.
Many thanks.
Justin, authenticating against the BLP API requires one of a few options to be in place. If you're only considering something around the Bloomberg (Professional) Terminal then you need to have a valid 'token' in place. When you light up a Bloomberg Terminal it creates a token and makes a BLP API 'delivery point' available on localhost:8194. When you log out of the Terminal the token remain valid and then delivery point remains intact. The token gets invalidated in two circumstances, either timeout (not even sure it will last overnight), and, the Bloomberg user logging in somewhere else (including on the Bloomberg phone app).
I should also say, that your application use case is constrained by licensing, in that you can only write display applications (as defined by exchange rules).
What some Bloomberg customers resort to if they have challenges around 24/7 applications, and, only have Bloomberg Terminals, is that they buy something called a Server API (SAPI). It allows a client/server pattern to be developed whereby the server portion can login in with its own credentials (application name), and, the client portion authenticates with the Terminal token/user. So, you could write the server component collecting data 24/7 but only delivers the analytics/results, etc when the Bloomberg Terminal users logs in.
If you're looking for something a little more systematic/autonomous then as a customer you should look at the Bloomberg Enterprise products such as B-PIPE, where the above need not apply, and you have a much more liberal accommodation of patterns.
As with all things finance, the devil is in the detail.. and depending on whether you're looking at exchange traded data or OTC, various rules and fees will apply.
Good luck

How can I connect with square production environment?

​My client is already using square as his payment system. I created a developer account by myself and I was able to process orders using sandbox environment. Now I would like to send orders to production environment for the existing account of my client.
I would like to know what is the process to accomplish that.
1.Does my client need to set a developer account by himself and share me his Application ID, Access token and location id?
2.if I finish the process to validate my developer account to process payments, will I be able to connect with the location id from my client?
3.Does he need to add my as a Team member in order to see his location in my account?
Thanks
Are you developing a custom application for one client that uses Square or are you going to have many clients that use Square use your application? If you’re developing a solution for one client you can ask them to create an application and configure their credentials to make the API calls. Otherwise you’ll want to use OAuth that will allow many sellers use your integration.

Can I use Stitch with multiple Xero accounts?

Stitch is an ETL that provides an integration with Xero accounting software:
https://www.stitchdata.com/integrations/xero/
I intended to use Stitch to allow the users of my app to connect their account with Xero, allowing us to store their Xero information for later analysis.
I was wondering if there is a way of setting and managing multiple Xero accounts with the same Stitch account, programatically (via an API, not via a UI).
I have seen the docs and they explain how to manually connecting your Stitch account with your (one) Xero account by manually authorizing:
https://www.stitchdata.com/docs/integrations/saas/xero#add-stitch-data-source
But I need to support multiple Xero accounts and to be able to set them up through my program.
the Xero API does support this. However depending on how the Stitch XeroAPI integration is setup they may only be allowing access to one org at a time. If you do request this feature and they decide to add it, we will work closely with them on the XeroAPI side.
Good luck. If you decide to build some kind of integration yourself shoot us a message at api#xero.com and we will help you through.

Creating a survey via the API with a Basic or Select account

Under "Scopes" the API documentation says "...the Create/Modify Surveys scope is available to Free (Basic) plans", but later contradicts that in the table showing "Platinum/Enterprise" as the minimum plan for the Create/Modify Surveys scope.
I am developing an application for a client that I believe has a Platinum account. However, I myself only have a Basic account and am reluctant to invest in a Platinum account for this small development project.
The client requires the creation a tool that generates surveys via the API, which seems pretty straightforward, except that I am unable to do so with my account. Is there some way my client can allow my account to access a development app on their account so I can test survey creation? Or could I do so myself with a Basic or Select account?
The Create/Modify Surveys scope will be moved down to the SELECT plan. Also, we will be providing developers time-limited full access to all the endpoints (except feature endpoints like benchmarks which requires the user to have bought the benchmark) when accessing their own account.
This should be available within a week or two. Check back at your app and the docs at https://developer.surveymonkey.com/ soon to see when the changes have been released.
Let us know if you have any more questions!

Can I control the list of chargeable connections in the IPP inside an Intuit App Center App?

I am developing an Intuit App Center app using the V3 SDK written in vb.net.
Is it possible to get/control the list of connected users that is listed in the Reports section of the Manage My Apps area in the Intuit Partner Platform? Specifically, the area where you view your connections and are able to disconnect users so you don't get charged for that connection.
I would like to be able to control that list from within my application for billing purposes. I have heard that it is possible to manipulate the list programmatically but I'm unsure how to do it.
This should definitely be do-able, but there's not a specific API for it.
There are really 3 components to tracking this information:
Have they EVER connected - you'll know this already because if they connected they will have gone through the OAuth process on your website and you'll have a token for them.
Are they connected NOW - you can test this by making an OAuth request to any of Intuit's services - if you get back a successful response, you know they are currently connected, vs. if you get back a 401 error you know the token is expired/no longer good.
Disconnecting them - you can choose to explicitly disconnect a user (and thus no longer get charged for their usage) by using the disconnect API call.
There is no billing API available.
You need to check it from the appcenter.
Ref - https://developer.intuit.com/docs/0025_quickbooksapi/0010_getting_started/0050_managing_your_app/connection_report
Thanks