I am sending request in amazon using GetReport API.
As per amazon document we can send only 15 request per minute.
How can get from amazon how many number of requests are pending ?
Amazon is providing any API to get this details ?
We are following below amazon document.
http://docs.developer.amazonservices.com/en_US/reports/Reports_GetReport.html
There is a separate page describing how request quotas (and therefore throttling) work: http://docs.developer.amazonservices.com/en_US/dev_guide/DG_Throttling.html
Related
Scenario: I'm build a NodeJs (NestJs Framework) application, Where I can get feedback from my clients (Amazon Product Purchaser) and Post its review on my Amazon Product page. I have successfully validated Amazon Order ID using SP-API endpoint sellingpartnerapi-na.amazon.com//orders/v0/orders/{orderId}, but I can't find any SP-API endpoint through which I can post Product Review on my Amazon Product Page.
Summary: I am trying to find an API endpoint (Amazon SP-API) through which I can post buyer review collected on my own website.
This use-case is impossible through SP-API.
You can't post a review on behalf on an Amazon customer.
The only thing you can do is redirect the customer to the review page.
Eventually you can add a parameter to pre-fil the form with 5 stars.
Here is the URL pattern to do so:
/review/create-review?&asin={{ ASIN }}:5
I have a scenario where my images are getting uploaded on S3 bucket using pre-signed URLs.
In case of high load scenario,
I want to let my user name about delay and ask him to wait.
After expiry period we get HTTP status code 403, but I just want to let him know about the high traffic situation
but question is
How do I find out the time taken by image to be uploaded on S3 pre-signed URL?
What all status codes can we get from PUT request on S3 pre-signed URL? (if can help me with some documentation for same; https://docs.aws.amazon.com/AWSJavaScriptSDK/latest/AWS/S3.html#getSignedUrlPromise-property does not have info about different status code retrieved from AWS)
How can I know about high traffic situation on S3 bucket?
How do I find out the time taken by image to be uploaded on S3 pre-signed URL?
This shouldn't matter. When the S3 pre-signed url expires, it will not stop uploads in progres. The expiry date is only important to initiate the upload.
How can I know about high traffic situation on S3 bucket?
You can't check this as this is AWS internal networking backend. you have no access to it nor AWS publishes such an info. The only issue is the speed of the internet connection of your clients.
What all status codes can we get from PUT request on S3 pre-signed URL?
I'm not sure what do you mean here.
Is there any guidelines/recommendations for the webhook URL that I can use for setting up the event notifications?
I am thinking of using something like this - /webhook/v1/{uniqueAppID}. The uniqueAppID changes for every envelope, I dynamically construct the URL and set it to the EventNotification object while creating the envelope.
The unique app id is used to track the response from DocuSign, So if at all there is any issue in parsing the response, I would know for which envelope/app id I have got the notification.
I read that the system will retry delivery for failures only after a successful acknowledgement is received from the webhook, In my case, it will be like having multiple webhooks. Will this setup cause any issues in retrying the failures? Does setting up the url like /webhook/v1?uniqueAppID={uniqueAppID} helps?
Thank You
Great questions.
First up, you don't have to use any kind of endpoint/URL schemes. You could have them all go one place. The information that you get from DocuSign in the payload would allow you to know everything you need about the envelope and if you need additional information - you could make API calls to determine this.
However, I would agree that if you need this information, using different endpoints would give you greater flexibility. Also, if it's different apps, you could, in theory, deploy them separately and thus the endpoint code would change without affecting other apps.
As for retry, this is done in case DocuSign does not get a 200, 201 or other HTTP response that's positive from your web server. If DocuSign gets 401 or 500 etc. If no response is received, DocuSign would retry again in 24 hours.
That should not impact your decision about the design.
One last thing to consider, you cannot be behind firewall/VPN etc. Highly recommend you consider a public cloud provider (Azure, AWS, Google) for your app to avoid networking issues.
When using envelope-level webhooks, the triggers and destination URI are embedded into that envelope. After the envelope enters a predefined state like 'sent' or 'completed', the writeback targets the URI that you provided. Unless you intentionally change this, it should remain envelope-specific.
This is different from our typical Connect setup, which would have a single URI per listener and envelopes writebacks would be directed to the listener URI at the time they're processed.
Any subsequent failure or retry attempts would follow the standard guidelines outlined here: How to get docusign webhook to retry on failure?
I have a NodeJS API and an AWS Load Balancer.
I need to process a credit card payment, and to do this I make 3 requests to my credit card provider with Axios.
On localhost, everything works fine, but when I put it online on AWS, I get 502 error. The payment and all internal functions is processed normally, but I can't get the response from the server.
The requests take around 7 seconds to complete.
Are there something special to do to get it working?
Tell me if you need a specific information.
I have created an API in Azure API Management to get data from a backend API.
The result from the backend API is paged, including a 'next' url in the response which must be used for the next request.
How to handle this 'next' url, in order to concatenate all paged responses and return the total of all paginated responses as one single response through Azure APIM?
That would be quite complex policy, but could be done by combining retry and send-request. In short keep retrying request every time with next url and concatenating results as long as there is next link in response.