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.
Related
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.
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 display only the images the client uploaded to instagram on their website. The client's user ID# is 176722013. According to the API this URL will provide just such a feed:
https://api.instagram.com/v1/users/176722013/media/recent
As indicated by the error message, I need to provide either a client_id or an auth_token. Since I don't want to deal with authentication I went ahead and created an "app" in instagram developers to get a client_id # 5b5a6e95469f465f9f70e4ebcf9ee3a6
Yet when I add it to the URL I still get an error that I needed to provide an auth_token. How does that make sense?
https://api.instagram.com/v1/users/176722013/media/recent?client_id=5b5a6e95469f465f9f70e4ebcf9ee3a6
The app is in sandbox mode. When I attempt to submit it for review I must provide the purpose for the app. Upon selecting " I want to display my Instagram posts on my website." as the purpose I get the following message:
You do not need to submit for review for this use case. If you are a
developer and you want to display Instagram content on your website,
then you do not need to submit your app for review. By using a client
in sandbox mode, you can still access the last 20 media of any sandbox
user that grants you permission.
I am truly at a loss for how to proceed. Thanks for any support
As of June 1st, 2016, you need access_token to access API, where did u read: either a client_id or an auth_token ?
authenticate and get access_token and use to get API response.
#snucky you don't need authentication but you do need the users permission - from what I gather, instagram is accessible only by registered users - so you still need the access token - but instead of a server-explicit you need client-implicit.
Make a http request from your client to the api/authorize with the ?client_id=ID AND A redirect_uri=http://yoursite.com/ when the user allows the application, you'll receive an access_token in the url, which you will then use in every subsquent instagram call
read more here
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 am new to linkedin api. I have a doubt regarding the api.
I am integrating the api in my application, so different user have to register in the linkedin to get the data using that api? Can it be pre registered and the user can get the data whatever he wants.
Suppose user wants to search about company. He will type the company name and will get the names of the company related to search. He should not log in in linked in before searching.
Is it possible?
If you are using the JavaScript API, then yes, you may need to have the user log in each time as the JavaScript API's authorization is cleared every time the user closes their browser.
If you are using the REST API, you can store the user's OAuth token and use that to make the calls on behalf of the user, saving them having to sign-in each time.