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.
Related
We have a use-case where we need to authorize a payment using a native payment on the web but use two different merchants. We want the user to press pay with Google and go through the ui but access google pay api with two different merchants. paymentsClient.loadPaymentData(paymentDataRequest).then(function(paymentData){ // if using gateway tokenization, pass this token without modification paymentToken = paymentData.paymentMethodData.tokenizationData.token; }).catch(function(err){ // show error in developer console for debugging console.error(err); });
is it possible to get the callback from this api request without a user interaction for the second request.
We have classified goods website where we do not have login but users can view products listed by other users. To view details of other users, they have to provide their contact details. To verify if user has provided the correct mobile number, we send back OTP code to the number. The API flow looks like:
//API to be hit when user fills form to get seller details of particular stock (this expects "stockId" and "mobile" as input):
POST /api/lead/
{
"stockId": 123,
"mobile": 9890384328
}
Response of API if "mobile" is already verified (Response code: 200):
{
"sellerName": "xyz",
"sellerMobile": "+123232312",
"sellerAddress": "21, park street, new york"
}
Response if "mobile" is NOT already verified (Response code: 403):
{
"OTP verification required. OTP is sent to the mobile number."
}
User sends back request again with OTP received on mobile to the same lead API:
Request Payload:
{
"stockId": 123,
"mobile": 9890384328,
"otp": 1234
}
It sends back seller details in response if OTP is correct. If OTP
provided is not correct, the response is:
{
"Incorrect OTP."
}
I see few issues in this API design:
This API is doing lots of working i.e. returning back seller details, returning back OTP, verifying OTP etc. We can easily break OTP related functionality to some other API. For example one API to generate OTP i.e. GET /api/otp/, other API to verify OTP i.e. POST api/verifyotp/. This would increase number of API calls from client i.e first client will initiate POST lead API, if number is not verified, client will hit OTP API. To verify by OTP it will call verifyOTP api. If it gets verified, it will call leads API to fetch seller details. So, basically it makes 4 API calls vs 2 API calls in above approach.
This is non-complaint with HATEOS which suggests "A REST client enters a REST application through a simple fixed URL. All future actions the client may take are discovered within resource representations returned from the server."
Can someone suggest which approach is better?
Simple answer: no.
It is called single responsibility principle for a reason.
Allowing for more than one responsibility in the your public API means that the API "endpoint" has to understand the different responsibilities to "dispatch" to the "correct" implementation for each of these aspects. Or you allow your dual-responsibility API design to corrupt your implementation by having a single thing providing that implementation.
And beyond that: when you have different responsibilities, the range of OK/error return codes simply turns more complicated. That simply makes "everything" harder. For you to write tests - but also for the clients using your API.
In your case, the user does:
use /api/lead first
to be told about "not verified"
use OTP generation API to get the verification code
to then use a specific OTP API to submit verification code
to then use /api/lead again
I am trying to fetch data using the Instagram API endpoints. Steps that I have followed
1. Register the client app.
2. Got the access token.
3. I am using this access token through out the url endpoints.
Ex. to get the data for recent media I am using this url endpoint: https://api.instagram.com/v1/users/self/media/recent/?access_token=ACCESS-TOKEN
However as I am in Sandbox mode, as per the documentation I get only the recent 20 media. Whereas my account contains in total 291 media.
Problems that I am facing:
Not able to get next_url in the paginationpart.
Usage of min_id and max_id in the url does not respond to any changes in the output or the data i.e fetched (Still get only 20 records/media)
Ex: https://api.instagram.com/v1/users/self/media/recent?access_token=XXXXXX&min_id=xxxxxx_xxxxx&max_id=xxxxxxx_xxxxxxx
Can anybody provide a solution as to how exactly I should get all of my historical data ?
You're in the sandbox mode so there's no way to achieve what you're trying to do before your app has been reviewed and approved (and gone live). From Instagram API documentation:
After your app has been reviewed and approved, you are ready to make it available to the general public. To switch your client from sandbox to live mode, you can use the button on the top section of the configuration screen for your app. When you are live, any Instagram user will be able to authorize your app, but you will have access only to the permissions that you were granted during the review.
Well, maybe you should try this library that allows you to scrape public info withou auth (client_id or access_token): https://github.com/raiym/instagram-php-scraper
$medias = Instagram::getMedias('kevin', 150);
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
I'm creating a tool for a person to login into their google+ account and to lists all communities they were created or joined. I had googling around for a day and read google+ api references, but I couldn't find any information on:
Url of the API for accessing user's created or joined comminities,
Request parameters to perform such query
My tool has already succeed to perform oauth login and get access_token and ready to make any API call, But now I'm stuck trying to find the right Url and requirements to perform the API call as I wanted.
Please help
There currently is no API method to do this. If you would like to see such a feature added, you can star this feature request.