Vai al contenuto principale
Un’app mobile usa esattamente la stessa Storefront API di un frontend web. L’unica differenza è che non gira sul dominio del negozio, quindi identifica il negozio con la chiave publishable su ogni richiesta.

Setup del client

Login del cliente & token

Il login (POST /auth/login) restituisce access_token (30 minuti) e refresh_token (7 giorni). Manda l’access token come Authorization: Bearer sulle chiamate dell’area account e rinnovalo con POST /auth/refresh. Il refresh è a rotazione: ogni rinnovo restituisce un refresh token nuovo e quello presentato viene superato. Regole per l’app:
  • Salva la coppia nuova a ogni refresh, nello storage sicuro del sistema: Keychain su iOS, un valore cifrato con una chiave dell’Android Keystore su Android, flutter_secure_storage in Flutter. Scrivi entrambi i token prima di usare il nuovo access token.
  • Un solo refresh alla volta: le richieste che ricevono 401 insieme aspettano lo stesso rinnovo invece di lanciarne uno ciascuna.
  • Riuso: se l’app si chiude fra la risposta e il salvataggio, al riavvio presenta il token vecchio. Entro 60 secondi l’API restituisce lo stesso token corrente; più tardi, per un account cliente, restituisce comunque il token corrente della sessione. Nessun logout forzato, purché tu salvi quello che ricevi.
  • Fine sessione: un 401 da /auth/refresh (auth.session_revoked, auth.refresh_token_reused, auth.refresh_token_invalid) o un 403 auth.tenant_unavailable chiudono la sessione: cancella i token e mostra il login.
  • Rete assente o 5xx: non cancellare nulla, riprova più tardi.
Flutter

Logout

  • Esci: se hai registrato il device per le notifiche, chiama prima DELETE /devices/{device_id} con l’access token (un device collegato all’account lo rimuove solo il suo proprietario). Poi POST /auth/logout con {"refresh_token": "..."} nel corpo chiude la sessione di questo dispositivo sul server. Infine cancella i token.
  • Esci da tutti i dispositivi: POST /auth/logout?all=true con l’access token (o il refresh token nel corpo). Da quel momento ogni token emesso prima risponde 401 auth.session_revoked.

Verifica in due passaggi (2FA)

Se il cliente ha attivato la 2FA, il login è in due passi:
  1. POST /auth/login risponde 401 auth.totp_required: mostra il campo del codice.
  2. Ripeti la stessa chiamata con totp_code. Lo stesso campo accetta un codice di recupero xxxxx-xxxxx: offri un link «Hai perso il telefono? Usa un codice di recupero». Ogni codice vale una volta sola (401 auth.totp_invalid se riusato).
Se l’app permette di attivare la 2FA:
  • POST /auth/2fa/setup con la password attuale restituisce secret e qr_uri; su mobile offri anche un pulsante che apre qr_uri nell’app di autenticazione.
  • POST /auth/2fa/verify con code e current_password attiva la 2FA e risponde con i token nuovi (le altre sessioni si chiudono: salvali) e con 10 recovery_codes. Mostrali una sola volta, con «Copia» e «Condividi», e chiedi conferma che il cliente li abbia salvati.
  • GET /auth/me espone recovery_codes_remaining: se scende vicino a 0, proponi di rigenerarli con POST /auth/2fa/recovery-codes (serve la password attuale).
  • POST /auth/2fa/disable accetta il codice dell’app o un codice di recupero e restituisce anch’esso token nuovi da salvare.
POST /users/me/change-password non chiude le sessioni, a meno che l’app non mandi l’header X-Session-Rotation: 1: in quel caso la risposta porta i token nuovi, da salvare subito al posto dei vecchi.

Notifiche push

Registra il device token del cliente per le notifiche transazionali (ordine spedito, ecc.) tramite gli endpoint device-push della Storefront API — vedi la API Reference.
Immagini e pagamenti funzionano come sul web: gli URL immagine vanno prefissati con l’origin, e il flusso di pagamento restituito da POST /checkout va completato con l’SDK nativo del gateway (Stripe/PayPal/…) quando serve. Prezzi e totali arrivano come stringhe decimali: vedi Costruisci uno storefront.