Set available status for teams user with power automate flow - httprequest

I am trying to set status available for my user with power automate flow, but everytime I close teams window user is set up to offline status.
It is possible to set available status to never change from available ?
I am using "Send an HTTP request to SharePoint" with configuration ->
Site address: url link
Method: PUT
Uri: /v1/me/forceavailability/
Headers: content-type application/json
JSON Body ->
{
"availability": "Availlable",
"desiredExpirationTime": "2021-08-29T14:29:01.834Z"
}

I found solution and looks functional.
if you set a meeting in calendar via Outlook (busy time) actually user will stay at busy and then with http request you can really set available status (works also with closed teams client)

Related

Is there a way to request Stripe for the cancellation reason of a subscription via API?

I am trying to query stripe for the cancellation reason of a subscription to feed this information into our CRM system.
The information I am looking for can be found in the dashboard here:
Stripe dashboard image
I found out that the browser sends a request to https://dashboard.stripe.com/v1/subscriptions/sub_xxx but with an API key that seems to belong to user request: uk_xxx. When I send a GET request to that endpoint with my API key sk_live_xxx I dont get the same data, i.e. the following information is missing:
{
"customer_portal_data": {
"cancellation_reason": "too_expensive",
"cancellation_reason_text": null
}
}
My question now: is there a way to query this information via the standard API from stripe?
This feature is only available in the Dashboard and Sigma right now and is not available via the API.

How can you find out which extensions a twitch streamer is using?

How can you check which extensions a twitch streamer is using?
For example, extensions used when
creating their 'About' page, or
when running custom codes (e.g. !event) during a stream
You can see the extensions active on a streamers page via the "Get User Active Extensions" API endpoint. Currently this involves a call to https://api.twitch.tv/helix/users/extensions with a user_id query string parameter
The current documentation for the endpoint is at https://dev.twitch.tv/docs/api/reference#get-user-active-extensions
As for "custom codes" you are out of luck, since there is no easy way to get what channel bot is in use and the commands that channel bot has. Since it will vary by channel and bot in use.

Hangouts Chat: how to retrieve project_id or client_id in incoming event request?

I have setup a fully operational chat bot in Hangouts Chat orchestrated by a tailored webserver. I would like now to be able to have this webserver to interact with other Hangouts bots that I created and to route some requests to some of my other servers that will have to know which bots initiated the event.
With other provider, such as Slack, the app_id is provided in the event request data.
But with hangouts, this is not the case. I could not find any data in the request body or headers that represent either project_id or client_id.
In a more simple way my question is : "How to identify the Hangouts bot that send me an event request?" :)
An event request's response will contain an Event instance in its body, which one of its fields will be an User object. That User object will contain a name field that will represent the user's id (whether it's a human or a bot).
It will look like this:
{
"name": "users/<id>",
"displayName": "<name that appears in the chat>",
"type": "BOT"
}
One month later, I finally found the time to answer my question :)
In order to identify the Hangouts project that is calling your server, when you receive an event from Hangouts Chat, you'll find in the incoming request the header Authorization whose value is something like Bearer abcd1234.
If you decode this JWToken (ie, abcd1234 in our example), in the resulting data, you'll have a field aud which is exactly the "project number" of your Hangouts app. This "project number" can be found at "https://console.cloud.google.com/home/dashboard?project=referenceofyourprojecthere".

Paypal REST API - getting 404 when trying to get webhook event with its HATEOS self url

I experimenting with Paypal REST API and I was stunned into a problem with webhooks.
I trying use the following tactic to verify event data - ensure that HATEOAS link with rel == "self" like https://api.sandbox.paypal.com/v1/notifications/webhooks-events/WH-6L177801XL962315K-5B870910V53268712 is present, and ensure that this link starts with expected API endpoint (set in web.config) and reloads event data with it, and use it as trusted event data.
But this tactic fails, it results to 404 instead of getting webhook data.
Who else used Paypal REST API webhooks? How you are verify that the event come from trusted event source?
Update
Was able to get more details on messages received. Response body:
Data [{\r\n \"name\": \"INVALID_RESOURCE_ID\",\r\n \"details\": [],\r\n \"message\": \"Resource id is invalid\"\r\n}]
Headers as JSON object: [{\r\n \"PROXY_SERVER_INFO\": [\r\n \"host=slcsbplatformapiserv3002.slc.paypal.com;threadId=370534\"\r\n ],\r\n \"Paypal-Debug-Id\": [\r\n \"e33a2f285d46f\"\r\n ],\r\n \"SERVER_INFO\": [\r\n \"webhooksplatformserv:ppaas_1_2.v1.notifications.webhooks-events.id.GET&CalThreadId=184&TopLevelTxnStartTime=14b4099eb05&Host=slcsbwebhooksplatformserv3002.slc.paypal.com&pid=29135\"\r\n ],\r\n \"Date\": [\r\n \"Sat, 31 Jan 2015 15:26:44 GMT\"\r\n ],\r\n \"Server\": [\r\n \"Apache-Coyote/1.1\"\r\n ]\r\n}]
The hateoas link should return the same payload as the original webhook event. So there seems to be some issue there.
However, if your intention is to validate if the event came from PayPal then the correct way is to validate the signature included in the webhooks header. This link has more details around the security aspects in webhooks.
https://developer.paypal.com/webapps/developer/docs/integration/direct/rest-webhooks-overview/#event-security

Instagram removed subscription for tag and when resubscribing it disappears even with successful response

I am running an application using Instagram's RealTime API and when I subscribe to a tag initially all is working fine, I can see for sure my response times are all within 100ms back to instagram but after about an hour, hour and a half they randomly delete my tag subscription. I check and I am not rate limited so I setup something to check my subscriptions every 10 minutes and if the tag I was subscribed to isn't returned from instagram to re-subscribe it. When running that I get back a response that it is subscribed -
{ object: 'tag',
object_id: '...',
aspect: 'media',
callback_url: 'http://...',
type: 'subscription',
id: '4479168' }
but then when I check my subscriptions again using the API Console it shows there are no subscriptions.
Does anyone have any idea why Instagram is deleting my subscription automatically.
Did you validate/confirm the subscription? You didn't mention doing it in your question so that leads me to think that maybe it's timing out after not being confirmed?
According to the API docs a POST to make any subscription will trigger a GET to your callback_url that will include:
hub.mode - This will be set to "subscribe"
hub.challenge - This will be set to a random string that your callback URL will need to echo back in order to verify you'd like to subscribe.
hub.verify_token - This will be set to whatever verify_token passed in with the subscription request.
The example URL given is:
http://your-callback.com/url/?hub.mode=subscribe&hub.challenge=15f7d1a91c1f40f8a748fd134752feb3&hub.verify_token=myVerifyToken
After parsing that callback you have to send a response including the hub.challenge value and you should have a lasting subscription.
As far as I can tell, this happens when Instagram decides you are not responding fast enough. I noticed 8 separate IPs posting the exact same subscription info (identical HTTP requests) and my app apparently has some transient lag issues. It appears that if responses are not sent immediately (100s of ms) then Instagram silently deletes the subscription and there's no way to find out.
Solution was to dump the subscription model and just poll them instead.