FAQs
LWA
Yes, clients can create different LWA security profiles for different environments etc based on the development processes on their side. Clients need to register at LWA public portal and also send Prime team relevant details during onboarding so that they can use these different LWA security profiles at different stages of development on their side.
In the Online Offer Construct, while it is possible for 3P Client authentication to occur before Login With Amazon (LWA) login, we strongly recommend it occur post LWA login. This allows for a better end user experience of completing LWA specific inputs first as the user starts their flow from an Amazon-owned cobranded offer landing page, followed by 3P Client authentication and related actions for offer redemption. More details can be found here.
Validity of auth code is just 5 min. It’s quite possible that the customer login step may take more than 5 min, so its better to first generate token-pair and then invoke login activity. Or do it the other way round where client can ask customer to first login and then initiate LWA handshake so that the generation of token-pair can be done immediately once auth code is shared with the client.
Client should generate the token pair and store it. As per our security team and LWA team recommendation, client should store it on the server side and don’t keep it in browser HTML. The token pair from browser HTML could be leaked by malicious scripts.
While LWA currently supports implicit grant type to retrieve token pair from front end webapps/websites, it is in the path for deprecation. Also, from a security point of view, LWA recommends only server side calls to /token endpoint to retrieve LWA token pair. Please refer to LWA guide for more details on implementation and other related suggestions.
APIs
Clients can write their own implementation of AWS Signature by following this documentation. There maybe some 3P resources as well that provides this feature, but Amazon do not recommend its usage as the new versions of the same are not in our control.
URL Path parameters like LWAAccessToken passed in customerIdentifier value should be URL encoded. The client customer identifier value shared by clients is approved by client to be stored in Amazon systems, currently there is no limitation set on the size of this string.
Yes, duplicate request or retry request is fault tolerable, and is left to the internal implementation. Clients can retry safely.
For both Benefit Discovery and Link Account APIs, the server side P99 latency on Amazon Prime side is around 140ms. The client side latency varies based on the region of operation of specific clients. Please refer to AWS documentation for specific latency details between AWS regions.
Retries on client side should always be done with an exponential backoff strategy. We advise retries to be done only for the error scenarios highlighted as ‘Retry - Yes’ in the respective integration guides provided for Prime APIs. Please refer to more detailed overview of duration of retry and related strategies in the Prime APIs integration guides here.
Notification System
While on Prime side, we don’t really have specific checks on the usage of same IAM role for accessing Prime APIs and also subscribing to Prime SNS topic, as a best practice, AWS recommends using an IAM role only for specific purposes and not combine their use cases. We will let 3P clients take a decision based on their internal development processes on the approach.
Clients can create any type of AWS SQS Queues based on the development processes and functional processes followed. As part of the onboarding process, Prime team will reach out for specific information on client’s AWS account and related details where SQS is setup to enable access to subscribe to Amazon Prime SNS.