Q: client.logon in Google Function expires - circuit-sdk

We are trying to deploy a bot in a google function as the example of Trivia but using the Client object.
It works, but the next day the bot appears as disconnected.
How long is a circuit session? Is it possible to create the client within a google function?
It is not a token problem, every time a new one is generated we store it in Datastore and collect it from there.

Google Cloud Functions are stateless, they get unloaded unless you have steady load, at which time the SDKs websocket connection closed, hence the bot is offline.
The Circuit SDK is not the best API to use in Cloud Functions, the REST API (as used in the trivia example) would work much better. The SDK is great for a browser app, or a NodeJS app that stays alive.
Now in terms of the Circuit SDK, you are correct, even though the token is still valid, the session will time out after one minute. Of course this is only the case if the app stops (i.e. websocket is closed).
More info on the GCF's execution environment can be found here.

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

Inconsistent webhook delivery of Twitter Account Activity API

I have successfully set up a DM bot with the Account Activity API. Everything works very well, except that sometimes the message sent to the bot (through the Twitter's web interface or mobile application) doesn’t fire a webhook to my server. The messages could be quick replies responses or plain text.
The reason is obviously not a downtime of my server since I tried to make a conversation between 2 webhook registered users (so my server receive the webhooks for both users) and for the same message sent, I have successfully received the webhook of the sender (the user) but not for the recipient (the bot).
As the bot isn’t in production yet, the reason is not an overload of messages. There is currently only 2 users that make conversations. From my experience, around 10% of messages are "lost".
I'm using the free (sandbox) Account Activity API tier, but as I understand the only differences between the free and paid versions are a higher number of subscriptions (I'm fine with 15) and the “Retries” feature. Regarding this feature, it is specified that “The Account Activity API provides a retry feature when the client’s web app does not return a ‘success’ 200 response for an account activity webhook event.”
It clearly states that the event failure concerns the client’s side, not the Twitter side. Considering this issue (my server doesn't receive the webhook at all), there is no guarantee that every event will be delivered even if in a paid plan.
This is a big inconvenience for bots since a button can only be clicked once, so the user must retry the conversation from the beginning (besides the fact that the bot "doesn't work"...)
So my questions are :
Is anyone here experience this issue ?
Is this a “bug or a feature” of the free Account Activity API ? I mean, at random the free tier doesn't fire the webhook on purpose (even if it's not specified in the docs) ?
Is there a way to see or measure the webhook failures Twitter side, via the dashboard for instance ?
A guess is that the events could be more accurate if the account is verified (with a blue badge) or hit a followers number threshold ? The treatment could be different due to the potential surge of events, so they are monitored with more ressources, thus more reliable ?
I already create a topic in the official Twitter forum and there is at least one other person in the same case, but no official answer from Twitter so far.
Thanks a lot !
BR,
Simon
I've got an official answer from Twitter :
Unfortunately it is not possible to achieve 100% delivery rate when there is only 1 delivery attempt for an event, which is why we have retries (and even then, retries are not a guarantee either). Things can go wrong; maybe internal issues in Twitter Data Centers, routing issues in the internet, hosting issues at your webhook, etc.
So from the time being, it seems that there's not way to have a 100% success delivery when you build a bot on Twitter.
Full answer can be read here.

soundcloud api how get clientId

On page https://developers.soundcloud.com/
Register a new app (Currently unavailable)
A question for developers. How soon will fix the registration of apps?
Is it possible to register my application in manual mode?
I need my clientId!
Apparently they haven't given out new client IDs for months (another user says so).
To answer your question though, no. As Soundcloud says when you attempt to register an app, "...we will no longer be processing API application requests at this time."
I'm trying to use the API too. It seems like we either need to use client IDs belonging to other people, wait an unspecified period of time, or there may be select uses of their API that don't require a client ID.
It depends on what kind of content you want to access.
If you need only public content than you can obtain the CLIENT ID from your AJAX requests made to soundcloud. Open network debugger in your browser and explore AJAX requests you should see some queries made to api.... and the query string should contain client id:
https://api-v2.soundcloud.com/tracks/687584815/playlists_without_albums?offset=85&limit=5&client_id=xxxxxxxxxxxxxxxxxxxx
Hope that helps.

Is it safe to retrieve credentials such as clientId, secret, etc. from an 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?

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