get_shipping_profile
Recupera l'indirizzo di spedizione salvato del cliente identificato (identity_linking), da chiamare PRIMA del checkout per evitare di chiedere l'indirizzo in chat. REQUISITI: - L'utente deve aver completato l'identity_linking: la richiesta deve portare un access token utente (header Authorization: Bearer <token>). OUTPUT: - resolved=true con DUE blocchi con le stesse chiavi: * masked = indirizzo mascherato di SOLA VISUALIZZAZIONE (città/regione/paese in chiaro; destinatario/via/CAP mascherati). Mostra QUESTI all'utente in chat. * tokens = handle opachi (es. NOM-..., VIA-..., CAP-...) da usare nelle chiamate ai tool: passa QUESTI valori nella destinazione di fulfillment di update_checkout. Il server li risolve in chiaro solo al confine con IGFS. MAPPATURA ESATTA sui campi della destination (non inventarne altri): tokens.recipient -> first_name (oppure "name": il server lo splitta) tokens.addressLine1 -> street_address [OBBLIGATORIO] tokens.addressLine2 -> extended_address tokens.postalCode -> postal_code [OBBLIGATORIO] Città/regione/paese si prendono dai valori 'masked', che li' sono in chiaro: masked.city -> address_locality, masked.region -> address_region, masked.country -> address_country. Regole: mostra all'utente SOLO i valori 'masked'; passa i 'tokens' ai tool; NON mostrare i 'tokens' all'utente né tentare di decodificarli; NON inventare né dedurre i valori in chiaro. - resolved=false se l'utente non è identificato o non ha un indirizzo salvato → in tal caso procedere col flusso alternativo (es. richiesta indirizzo sull'HPP wallet). PARAMETRI: - merchantCode (obbligatorio): codice merchant (es. "CONAD").
Each store has its own status page. To find more, search the directory.
Input schema
{
"type": "object",
"required": [
"merchantCode"
],
"properties": {
"merchantCode": {
"type": "string",
"description": "Merchant identifier (e.g. CONAD)"
}
}
}
