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
Related
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?
I'm new to Xero API's and I'm trying to understand a thing.
In my Company we currently have various different “organisations” within Xero, and this number will be growing in the near future.
We also have a 3rd party web application we use for technical and management data – to which we now would like to add financial data, mostly in the form of exported Xero reports.
We had been looking at the API functionality – however as I understand it Xero is unable to grant a subset of permissions to API calls – i.e. anyone with API access would have the same level of access a standard user – so aside from being able to pull the reports we require, they would also have access to all other data, such as transactional data, account numbers, creation and deletion of invoices etc. etc. Please can you confirm whether this would be the case?
In short terms: we need to restrict the API calls to the reports only, is this possible?
If not, does Xero have a functionality where reports can be automatically exported to an external location – such as a cloud service or an FTP site or similar?
Many thanks in advance
You're correct. Once you connect an app to the API it has access to all the accounting endpoints. Payroll endpoints are the only ones that require additional scopes.
And no, unfortunately there's no way to schedule report exports either. Sorry!
I've looked briefly through Spotify's API documentation to try and see what exactly can be done with the API. I'm trying to do some data analysis on Spotify data, specifically on user listens / user playlists. However, as far as I can tell, the only way to uncover that information is through OAuth, and each user whose play information I desire would need to explicitly grant permission to my app to use their information. Since I am not building a user-facing app and am interested in doing mass analysis on many users at once, I don't think this would work for my purposes.
My question - is there any way to return multiple users' listening habits through a script that pulls data from Spotify using its API? Or is that possible strictly by way of an application that one user at a time gives authentication to when they load an app that uses this API?
is there any way to return multiple users' listening habits through a script that pulls data from Spotify using its API?
Spotify doesn't expose users' listening habits unless they authorized the app requesting it (I think this is what you meant when you said "through OAuth"). There's pretty big privacy reasons for not exposing users' data to the world.
I want to make a desktop application which will need to use a 3rd party REST API to get information. However, the number of requests is limited by the API Key. If I use one API key for all users, the request quota will be exhausted really fast. Now, is it standard (and legal) to make each user sign up for his/her own API key? How are API keys used in context of open-source projects?
To generate the API key, I want to make a sign up form within the application, where the user puts in his/her information and the application sends those information to the 3rd party website to get an API key. Does that sound right?
In general the use of an API is limited to the requests from one machine and not to the API key most of the time.
Again depending of the type of third party services you are using, but the requests to the service should be established by the client not the server.
For example if you want to know geographic coordinates from a specific place, but obviously you can't ask the user directly for GPS coordinates. So you implement the Google Maps Javascript Library into your app which requests the Google API for the coordinates to the human readable address and returns it to the client. This in turn sends the data to your server.
In this way your server never comes into contact with the third party service.
If you have sensitive data or data which shouldn't be manipulated by the user you have to request from your server directly of course. But take a look into the documentation of the service before hack something together which isn't in the intention of the service provider.
Never ever try to outwit a service provider. They will detect your inappropriate use and block you for all time!
I like to build a system that will allow users to "commit buy" a deal, but will only be charged after a minimum # of committers are reached. The time span in which the "deal" will continue can be either weekly or monthly.
I like to stay away from building one from the ground up as much as possible.
I know there's another thread on StackOverflow that asked paypal, amazon, or google checkout API to serve this purpose, but this seems too much like a hack?
I did some reading on using a gateway like Authorize.net to process credit card information and they can store the user information and has a service like pay-as-you-go. Would using their API be a better choice? Can their pay-as-you-go method provide the system that I'm looking for?
I did some reading on using a gateway like Authorize.net to process
credit card information and they can store the user information and
has a service like pay-as-you-go. Would using their API be a better
choice?
I have used Authorize.net for recurring payments and it is easy to implement if you are fluent in working with a web service (regardless of language). You can integrate with them without the user needing to leave your website and without storing the user's credit card information.
However, you will be receiving the user's credit card number to implement such a model, and there are still precautions to be taken (versus redirecting to a secure third party site to receive the number).
Refine your question to be more specific to receive more specific answers.