Affiliazione Amazon: Guida Completa per migrazione da PAAPI a Creators API

Se gestisci un sito di affiliazione, un comparatore prezzi, o qualsiasi applicazione che si appoggia alle API di Amazon per recuperare prodotti, prezzi e immagini… allora questo articolo è assolutamente per te.

Amazon ha inviato questa mail a tutti gli sviluppatori registrati al programma PAAPI:

“We will retire the PAAPI v5 endpoint on May 15, 2026. To avoid any service disruptions, please migrate to the new Creators API endpoint by that date.”

15 maggio 2026. Non è lontanissimo, e se non migri in tempo il tuo sito smette di funzionare.

In questo articolo ti guiderò passo per passo attraverso l'intera migrazione, con esempi reali. Ti mostrerò anche tutti gli errori in cui mi sono imbattuto durante lo sviluppo, perché nella realtà le cose non vanno mai lisce al primo colpo, e come li ho risolti.

Cos'è l'Affiliazione Amazon e cosa sono le PAAPI

Prima di entrare nel vivo della migrazione, facciamo un passo indietro per chi non conosce il contesto. Anche se sei uno sviluppatore esperto, questa parte ti tornerà utile per spiegare il problema ai tuoi clienti o al tuo team.

Cos'è il Programma di Affiliazione Amazon?

Amazon Associates, o Programma di Affiliazione Amazon, è uno dei programmi di affiliazione più diffusi al mondo. Il meccanismo è semplice: chiunque può iscriversi, ottenere link speciali ai prodotti Amazon, e guadagnare una commissione ogni volta che qualcuno acquista tramite quel link.

Fin qui nulla di tecnico. Il problema nasce quando si vuole fare le cose in grande.

Immagina di gestire un sito come un comparatore prezzi, un aggregatore di offerte o uno shop tematico con centinaia o migliaia di prodotti Amazon.

Aggiornare prezzi, disponibilità e immagini a mano è impossibile, ecco perchè hai bisogno di automatizzare tutto questo.

Ed è qui che entrano in gioco le API.

Cosa sono le PAAPI 5

PAAPI sta per Product Advertising API, letteralmente “API per la pubblicità di prodotti“. È il servizio messo a disposizione da Amazon che permette agli sviluppatori di interrogare il catalogo Amazon in modo programmatico.

Con le PAAPI puoi fare cose come:

• Cercare prodotti per parola chiave: SearchItems
• Recuperare i dettagli di un prodotto specifico tramite codice ASIN: GetItems
• Ottenere prezzi, disponibilità, immagini, recensioni e molto altro in tempo reale

In pratica, invece di fare copia-incolla manuale dei prodotti, il tuo sito chiama Amazon ogni tot minuti, recupera i dati aggiornati e li mostra agli utenti.

Automatico, scalabile ma soprattutto sempre aggiornato.

Chi usa le PAAPI

Praticamente chiunque abbia un progetto serio di affiliazione Amazon: siti di offerte come quelli che trovate cercando coupon e sconti, comparatori di prezzi, blog tematici che mostrano prodotti correlati agli articoli, app mobile di shopping, e così via. È un ecosistema enorme.

Io ad esempio utilizzo le PAAPI di Amazon sia in questo blog, tramite il plugin AAWP, che sul mio comparatore online trovaOfferteSconti.it

Perché Amazon sta cambiando tutto

La versione attuale, ovvero le PAAPI v5, usa un sistema di autenticazione chiamato AWS Signature Version 4. È un meccanismo potente ma complesso, nato per i servizi cloud professionali di Amazon Web Services. Per chi sviluppa siti di affiliazione è spesso eccessivamente complicato da implementare e da mantenere.

La nuova Creators API adotta OAuth 2.0, che è lo standard moderno usato da praticamente tutti i grandi provider come Google, Facebook, Spotify e GitHub. È più semplice, più sicuro, e gestisce automaticamente il rinnovo delle credenziali.

In sostanza Amazon sta modernizzando la propria infrastruttura, e noi sviluppatori dobbiamo adeguarci.

Con una scadenza precisa: 15 maggio 2026.

Detto questo, iniziamo con la migrazione vera e propria.

Cosa cambia con le Creators API e perchè

Prima di toccare una riga di codice, è fondamentale capire cosa cambia tra PAAPI v5 e la nuova Creators API.

Le differenze sono sostanzialmente quattro:

Prima differenza: l'autenticazione. PAAPI v5 usava AWS Signature Version 4, un meccanismo di firma crittografica complesso che richiedeva di firmare ogni singola richiesta con Access Key e Secret Key. La nuova Creators API usa OAuth 2.0 standard, nella variante Login with Amazon (LwA) – lo stesso sistema usato da tutto l'ecosistema Amazon moderno: Alexa, Selling Partner API, e così via. Si ottiene un token Bearer valido un'ora, lo si riusa per tutte le chiamate, e quando scade se ne richiede uno nuovo.

Seconda differenza: gli endpoint. Si passa da webservices.amazon.it/paapi5/... a creatorsapi.amazon/catalog/v1/.... URL completamente diversi.

Terza differenza: i parametri. Tutti i nomi di campi nelle richieste e nelle risposte passano da PascalCase ItemIds, PartnerTag, ItemInfo a lowerCamelCase: itemIds, partnerTag, itemInfo. Sembra una cosa piccola, ma se hai un DTO Java con annotazioni Jackson tarate sul vecchio formato, dovrai aggiornarli tutti, stesso discorso se usi una classe php o python.

Quarta differenza: le credenziali. Questo è il punto che causa più confusione. Le tue credenziali PAAPI esistenti – Access Key e Secret Key non funzionano con la nuova API. Dovrai generare nuove credenziali OAuth 2.0 direttamente da Associates Central.

La buona notizia è che la logica di business rimane la stessa: SearchItems, GetItems, GetVariations funzionano come prima. Cambia solo il come, non il cosa.

Come generare credenziali per le Creators API

Il primo passo concreto è ottenere le nuove credenziali. Andiamo su Associates Central.

Nel menu in alto, cercate la voce Tools, poi Creators API.

Da questa sezione potrai:

• Creare una nuova applicazione: dai un nome descrittivo alla tua app

• Generare le credenziali: clicca su Create Credential

A questo punto ti vengono mostrati tre valori fondamentali:

• Credential ID: è il tuo nuovo client_id
• Secret: è il tuo nuovo client_secret
• Version: dipende dalla vostra regione geografica

⚠️ Attenzione importante: il Credential Secret viene mostrato una sola volta. Copialo immediatamente e conservalo in modo sicuro. Se lo perdi dovete rigenerare le credenziali.

Una nota sulla versione delle credenziali. Amazon ha rilasciato due generazioni di Creators API: la v2.x e la più recente v3.x. In questo tutorial utilizziamo le credenziali v3.x, che usano il sistema Login with Amazon lo stesso standard OAuth2 usato da tutto l'ecosistema Amazon moderno. È la scelta corretta per un progetto nuovo: più semplice, più pulita e con maggiore longevità.

Per quanto riguarda la Version, ecco la tabella delle regioni per le credenziali:

In particolare

• NA (Nord America) → Version 3.1, token endpoint: api.amazon.com/auth/o2/token
• EU (Europa, inclusa Italia) → Version 3.2, token endpoint: api.amazon.co.uk/auth/o2/token
• FE (Far East) → Version 3.3, token endpoint: api.amazon.co.jp/auth/o2/token

Noi lavoriamo con www.amazon.it, quindi siamo in EU, Version 3.2.

Verifichiamo le credenziali con cURL

Prima di scrivere qualsiasi riga di codice, verifichiamo che le credenziali funzionino con una semplice chiamata curl.

Ricorda che il flusso per invocare le API di ricerca è questo:

1. Generare il token (dura 1 ora)
2. Copiare il token
3. Usare il token per invocare le api di ricerca

Per le credenziali v3.x il token si ottiene con una chiamata JSON non più form-encoded come nelle versioni precedenti:

curl -X POST https://api.amazon.co.uk/auth/o2/token \
  -H "Content-Type: application/json" \
  -d '{
    "grant_type": "client_credentials",
    "client_id": "IL_VOSTRO_CLIENT_ID",
    "client_secret": "IL_VOSTRO_CLIENT_SECRET",
    "scope": "creatorsapi::default"
  }'

Due cose da notare rispetto alle versioni precedenti: il body è JSON, non form-encoded, e lo scope è creatorsapi::default con i doppi due punti non lo slash.

Se tutto va bene, riceverai:

{
  "access_token": "Atc|MQICIJvSKVTZ...",
  "scope": "creatorsapi::default",
  "token_type": "bearer",
  "expires_in": 3600
}

Ora testiamo una chiamata API reale. Prendi un ASIN qualsiasi da amazon.it e lancia:

curl -X POST https://creatorsapi.amazon/catalog/v1/getItems \
  -H "Authorization: Bearer IL_VOSTRO_TOKEN" \
  -H "Content-Type: application/json" \
  -H "x-marketplace: www.amazon.it" \
  -d '{
    "itemIds": ["B08G9J44ZN"],
    "itemIdType": "ASIN",
    "marketplace": "www.amazon.it",
    "partnerTag": "il-vostro-tag",
    "resources": ["itemInfo.title"]
  }'

Nota la semplicità dell'header Authorization: solo Bearer TOKEN, niente suffissi aggiuntivi. Con le credenziali v3.x è così, pulito e standard.

Bene, le credenziali funzionano. Ora passiamo al codice.

Configurazione con Spring Boot

In questo articolo ti mostrerò alcuni pezzi di codice da utilizzare per andare ad integrare le nuove creators API in un progetto Java Spring Boot, ma le modifiche saranno poi molto simili anche per altri linguaggi di programmazione.

Sul sito ufficiale Amazon trovi tutte le info, compresi i nuovi SDK

Dipendenze Maven

Come prima cosa dovrai aggiungere due dipendenze maven al pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-oauth2-client</artifactId>
</dependency>
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-webflux</artifactId>
</dependency>

oauth2-client gestisce tutto il ciclo di vita del token OAuth2. webflux ti dà accesso a WebClient, il client HTTP moderno di Spring che sostituisce il vecchio RestTemplate.

Properties

Aggiungi la configurazione OAuth2:

# OAuth2 - Creators API Amazon
spring.security.oauth2.client.registration.amazon-creators.client-id=${AMAZON_CLIENT_ID}
spring.security.oauth2.client.registration.amazon-creators.client-secret=${AMAZON_CLIENT_SECRET}
spring.security.oauth2.client.registration.amazon-creators.authorization-grant-type=client_credentials
spring.security.oauth2.client.registration.amazon-creators.client-authentication-method=client_secret_post
spring.security.oauth2.client.registration.amazon-creators.scope=creatorsapi::default

spring.security.oauth2.client.provider.amazon-creators.token-uri=https://api.amazon.co.uk/auth/o2/token

# Parametri Creators API
amazon.creators.marketplace=www.amazon.it

Rispetto alle versioni precedenti delle Creators API, la configurazione è più snella: nessun amazon.creators.version, e il metodo di autenticazione è client_secret_post le credenziali vengono passate nel body della richiesta token, come richiesto dall'endpoint LwA di Amazon.

Nota che i valori sensibili client-id e client-secret vengono letti da variabili d'ambiente. Non mettere mai credenziali in chiaro nei file di configurazione che finiscono su Git.

File properties esterno per la produzione

Su un server di produzione, la configurazione con le credenziali reali è meglio tenerla fuori dal jar, in un file esterno che non viene mai committato su Git.

Spring Boot ha una gerarchia di caricamento delle properties: il file esterno vince sempre su quello interno al jar, ma le properties non presenti nel file esterno vengono comunque lette dal jar. I due file si fondono.

/opt/mia-app/
├── app.jar
└── config/
    └── application-prd.properties ← file esterno con i segreti

Nel nostro caso, dato che il jar si trova in una cartella che cambia ad ogni deploy con il numero di versione, usiamo uno script di avvio che passa il path del file di config in modo esplicito:

java -jar "${JAR_FILE}" \
  --spring.config.location=classpath:/,/opt/mia-app/config/

E impostiamo i permessi corretti sul file:

chmod 600 /opt/mia-app/config/application-prd.properties

Classe di configurazione AmazonCreatorsApiConfig

Con le credenziali v3.x la classe di configurazione è notevolmente più semplice rispetto alle versioni precedenti. Non serve alcun filtro custom, Spring gestisce il token Bearer in modo completamente standard:

@Configuration
public class AmazonCreatorsApiConfig {

    @Value("${amazon.creators.marketplace}")
    private String marketplace;

    @Bean
    public OAuth2AuthorizedClientManager authorizedClientManager(
            ClientRegistrationRepository clientRegistrationRepository) {

        var clientService =
            new InMemoryOAuth2AuthorizedClientService(clientRegistrationRepository);

        var provider = OAuth2AuthorizedClientProviderBuilder.builder()
                .clientCredentials()
                .build();

        var manager = new AuthorizedClientServiceOAuth2AuthorizedClientManager(
                clientRegistrationRepository, clientService);
        manager.setAuthorizedClientProvider(provider);

        return manager;
    }

    @Bean
    public WebClient amazonCreatorsWebClient(
            OAuth2AuthorizedClientManager authorizedClientManager) {

        var oauth2 = new ServletOAuth2AuthorizedClientExchangeFilterFunction(
            authorizedClientManager);
        oauth2.setDefaultClientRegistrationId("amazon-creators");

        return WebClient.builder()
                .baseUrl("https://creatorsapi.amazon/catalog/v1")
                .apply(oauth2.oauth2Configuration())
                .defaultHeader(HttpHeaders.CONTENT_TYPE,
                    MediaType.APPLICATION_JSON_VALUE)
                .defaultHeader("x-marketplace", marketplace)
                .build();
    }
}

Confrontala con quello che avresti dovuto scrivere con le credenziali v2.x: niente @Value per la versione, niente filtro lambda per manipolare l'header Authorization, niente headers.remove() e headers.add(). Spring aggiunge Authorization: Bearer TOKEN automaticamente e va benissimo così.

AuthorizedClientServiceOAuth2AuthorizedClientManager lo usiamo invece del DefaultOAuth2AuthorizedClientManager perché la nostra app è una REST API senza sessioni HTTP. Questo manager usa un servizio in-memory per cachare i token. Quando il token scade, Spring lo rinnova automaticamente alla chiamata successiva, non devi gestire nulla a mano.

Verifica del Token allo StartUp

Prima di integrare la nuova API nella logica di business, creiamo un componente che al momento dello startup verifica che il token OAuth2 venga ottenuto correttamente. Ti consiglio di abilitarlo solo nel profilo dev con l'annotazione @Profile("dev"), così in produzione non viene mai eseguito:

@Component
@Profile("dev")
public class AmazonCreatorsApiStartupCheck implements ApplicationRunner {

    private static final Logger logger =
        LoggerFactory.getLogger(AmazonCreatorsApiStartupCheck.class);

    private final OAuth2AuthorizedClientManager authorizedClientManager;

    public AmazonCreatorsApiStartupCheck(
            OAuth2AuthorizedClientManager authorizedClientManager) {
        this.authorizedClientManager = authorizedClientManager;
    }

    @Override
    public void run(ApplicationArguments args) {
        try {
            var authorizeRequest = OAuth2AuthorizeRequest
                    .withClientRegistrationId("amazon-creators")
                    .principal("startup-check")
                    .build();

            var authorizedClient =
                authorizedClientManager.authorize(authorizeRequest);

            if (authorizedClient != null &&
                    authorizedClient.getAccessToken() != null) {
                logger.info("✅ Token OAuth2 ottenuto con successo!");
                logger.info("✅ Scadenza: {}",
                    authorizedClient.getAccessToken().getExpiresAt());
            } else {
                logger.error("❌ Token OAuth2 non ottenuto");
            }
        } catch (Exception e) {
            logger.error("❌ Errore token OAuth2: {}", e.getMessage());
        }
    }
}

Se vedi il log con la spunta verde, sei a posto con il token di autorizzazione e potrai procedere con il codice.

Aggiornamento dei DTO (Modelli)

Qui c'è un lavoro di rifinitura importante. I DTO Java ovvero le classi che rappresentano la risposta di Amazon, sono stati creati per la vecchia API con annotazioni @JsonProperty in PascalCase: @JsonProperty("ASIN"), @JsonProperty("ItemInfo"), @JsonProperty("Images") e così via.

La nuova Creators API risponde in lowerCamelCase: asin, itemInfo, images.

La soluzione elegante è aggiungere un @JsonAlias su ogni campo. @JsonProperty rimane il nome principale, quello usato per serializzare, ma @JsonAlias permette di accettare anche nomi alternativi in deserializzazione. In questo modo i DTO funzionano sia con la vecchia API che con la nuova, senza rompere niente.

@JsonProperty("ASIN")
@JsonAlias("asin")
private String aSIN;

@JsonProperty("ItemInfo")
@JsonAlias("itemInfo")
private ItemInfo itemInfo;

@JsonProperty("Images")
@JsonAlias("images")
private Images images;

@JsonProperty("OffersV2")
@JsonAlias({"offersV2", "offers"})
private OffersV2 offersV2;

Dovrai fare lo stesso su tutte le classi figlie: ItemInfo, Images, BrowseNodeInfo, OffersV2, e tutte le classi annidate. È un po' di lavoro meccanico, ma una volta fatto non ci si pensa più.

Un caso particolare riguarda gli acronimi. Per un campo come violatesMAP, la nuova API potrebbe restituirlo come violatesMAP o violatesMap. Per coprire entrambi i casi usate un array in @JsonAlias:

@JsonProperty("ViolatesMAP")
@JsonAlias({"violatesMAP", "violatesMap"})
private Boolean violatesMAP;

I nuovi metodi nel Service

La strategia di migrazione che ti consiglio è non toccare i metodi esistenti (PAAPI 5). Aggiungi i nuovi metodi Creator Api nell'interfaccia e nell'implementazione, fai girare vecchi e nuovi in parallelo, verifica che i risultati siano equivalenti, e solo quando sei sicuro fai lo switch definitivo.

Nell'interfaccia aggiungiamo:

// Nuovi metodi Creators API
List<ProdottoAmazon> searchAmazonItemsV2(String pattern, Integer itempage,
    Integer minprice, Integer maxprice, Boolean solo_offerta, Website website);
ProdottoAmazon getAmazonItemV2(String asin, Website website);
List<ProdottoAmazon> getAmazonItemsV2(String asins, Website website);

Nell'implementazione, la prima cosa da fare è iniettare il WebClient:

private final WebClient amazonCreatorsWebClient;

public ProdottoAmazonServiceImpl(WebClient amazonCreatorsWebClient) {
    this.amazonCreatorsWebClient = amazonCreatorsWebClient;
}

Poi implementiamo i metodi helper per costruire le request. Notate il lowerCamelCase nei nomi dei parametri e nelle risorse è la differenza fondamentale rispetto alla vecchia API:

private Map<String, Object> buildSearchRequest(String pattern, Integer itempage,
        Integer minprice, Integer maxprice, Boolean solo_offerta, Website website) {

    Map<String, Object> req = new HashMap<>();
    req.put("keywords", pattern);
    req.put("itemPage", itempage);
    req.put("minPrice", minprice);
    req.put("partnerTag", website.getAmazonPartnerTag());
    req.put("partnerType", "Associates");
    req.put("marketplace", "www.amazon.it");
    req.put("resources", List.of(
            "browseNodeInfo.browseNodes",
            "images.primary.large",
            "images.variants.large",
            "itemInfo.title",
            "itemInfo.externalIds",
            "offersV2.listings.condition",
            "offersV2.listings.price"
    ));
    if (maxprice != null) req.put("maxPrice", maxprice);
    if (solo_offerta) req.put("minSavingPercent", 1);
    return req;
}

private Map<String, Object> buildGetRequest(List<String> asinList, Website website) {
    Map<String, Object> req = new HashMap<>();
    req.put("itemIds", asinList);
    req.put("itemIdType", "ASIN");
    req.put("partnerTag", website.getAmazonPartnerTag());
    req.put("partnerType", "Associates");
    req.put("marketplace", "www.amazon.it");
    req.put("resources", List.of(
            "browseNodeInfo.browseNodes",
            "images.primary.large",
            "images.variants.large",
            "itemInfo.title",
            "itemInfo.externalIds",
            "offersV2.listings.condition",
            "offersV2.listings.price"
    ));
    return req;
}

I metodi di parsing della risposta sfruttano gli @JsonAlias che abbiamo aggiunto ai DTO ObjectMapper fa tutto da solo:

private List<ProdottoAmazon> parseSearchResponse(JsonNode response) {
    List<ProdottoAmazon> prodotti = new ArrayList<>();
    if (response == null) return prodotti;

    JsonNode items = response.path("searchResult").path("items");
    if (items.isMissingNode() || !items.isArray()) return prodotti;

    ObjectMapper mapper = new ObjectMapper();
    for (JsonNode jsonItem : items) {
        try {
            prodotti.add(mapper.treeToValue(jsonItem, ProdottoAmazon.class));
        } catch (Exception e) {
            logger.error("[CreatorsAPI] Errore parsing item: {}", e.getMessage());
        }
    }
    return prodotti;
}

E infine i metodi pubblici:

@Cacheable("searchAmazonItemsV2")
public List<ProdottoAmazon> searchAmazonItemsV2(String pattern, Integer itempage,
        Integer minprice, Integer maxprice, Boolean solo_offerta, Website website) {

    var request = buildSearchRequest(pattern, itempage, minprice, maxprice,
        solo_offerta, website);
    try {
        JsonNode response = amazonCreatorsWebClient.post()
                .uri("/searchItems")
                .bodyValue(request)
                .retrieve()
                .bodyToMono(JsonNode.class)
                .block();
        return parseSearchResponse(response);
    } catch (WebClientResponseException e) {
        logger.error("[CreatorsAPI] Errore search: status={}, body={}",
            e.getStatusCode(), e.getResponseBodyAsString());
        return new ArrayList<>();
    }
}

Errori reali che ho riscontrato

Questa è la parte che trovo più utile, perché questi sono errori reali che ho incontrato durante lo sviluppo. Se li conoscete in anticipo, risparmiate ore di debugging.

Errore 1: Token endpoint sbagliato

Il primo istinto è usare api.amazon.com/auth/o2/token per tutte le regioni. Sbagliato: quell'endpoint è corretto solo per le credenziali NA (Nord America). Per le credenziali EU, quindi chi lavora su amazon.it, amazon.de, amazon.fr e tutto il resto dell'Europa il token endpoint corretto è:

Stesso errore, stesso 401, zero messaggi utili.

Errore 2: Scope con slash invece di doppi due punti

Le vecchie credenziali v2.x usavano creatorsapi/default con lo slash. Le v3.x usano creatorsapi::default con i doppi due punti. Se copi da un vecchio esempio trovato online e lo scope è sbagliato, riceverai un 401 immediato.

Errore 3: client_authentication_method sbagliato

Spring Security supporta due modalità per inviare le credenziali alla richiesta di token:

client_secret_basic che le mette nell'header Authorization come Basic Auth e client_secret_post che le mette nel body della richiesta.

L'endpoint LwA di Amazon si aspetta client_secret_post se usi client_secret_basic, il token non viene emesso.

Errore 4: Resources in PascalCase

Le resources nella request devono essere in lowerCamelCase: images.primary.large, itemInfo.title. Se passate Images.Primary.Large come nella vecchia PAAPI, ricevete 500 Internal Server Error senza spiegazioni. Controllate sempre il body della request con un log prima di andare in produzione.

Errore 5: ASIN con virgolette nella stringa

Se nel tuo codice costruisci la lista di ASIN come stringa JSON a mano per la vecchia PAAPI, tipo "\"B001234\",\"B005678\"" quando passi quella stringa al nuovo metodo che la splitta e crea una List<String>, ogni ASIN avrà le virgolette come parte del valore. La soluzione: pulire con .replace("\"", "").trim() durante il parsing della stringa.

List<String> asinList = Arrays.stream(asins.split(","))
        .map(asin -> asin.replace("\"", "").trim())
        .collect(Collectors.toList());

Strategia di Migrazione Graduale

Il mio consiglio è di non migrare tutto in una volta, ma di seguire questa roadmap:

Fase 1: Adesso → Implementa i metodi V2 in parallelo a quelli esistenti. Non toccare nulla che funziona già.

Fase 2: Test → Chiama i metodi V2 in parallelo ai vecchi e confronta i risultati. Verifica che i dati siano equivalenti.

Fase 3: Marzo/Aprile 2026 → Switcha le chiamate nel codice di produzione dai metodi vecchi ai nuovi V2. Monitora attentamente i risultati.

Fase 4: Dopo il 15 maggio 2026 → Rimuovi i metodi vecchi e la classe AWSV4Auth che non serve più.

Questo approccio ti permette di migrare senza rischi, con la possibilità di tornare indietro in qualsiasi momento prima della deadline.

Il mio video su YouTube

Questo il video completo su YouTube

Conclusione

Bene, questo è tutto quello che ti serve per migrare da Amazon PAAPI v5 alla nuova Creators API in Spring Boot, ma come ti ho detto il 90% dei consigli che ti fornisco vanno bene anche per altri linguaggi di programmazione.

Riepiloghiamo i punti chiave:

• Genera le nuove credenziali v3.x da Associates Central, non usare quelle vecchie
• Per l'Italia usa il token endpoint EU: api.amazon.co.uk/auth/o2/token
• Lo scope è creatorsapi::default con i doppi due punti
• Il metodo di autenticazione Spring è client_secret_post
• Il WebClient non richiede alcun filtro custom, Spring gestisce il token Bearer automaticamente
• Aggiorna tutti i DTO con @JsonAlias per accettare sia PascalCase che lowerCamelCase
• Migra gradualmente con metodi V2 in parallelo ai vecchi
• Deadline: 15 maggio 2026

Se questo articolo ti è stato utile, lasciami un feedback nei commenti: rispondo sempre a tutti

Link utili

• Programma Affiliazione Amazon
• Documentazione Creators API
• Spring Security OAuth2