# GET /partner-portal/me Lire votre profil de partenaire et la liste des marques qui vous ont accrédité. Session de compte partenaire, aucun droit de clef d'API. Source : https://docs.sealtrust.io/reference/get-partner-portal-me/ --- Vous lisez votre profil de partenaire et la liste des marques qui vous ont accrédité, avec le métier reconnu pour chacune. En quittant cette page, vous saurez comment présenter votre session, ce que contient la réponse, et pourquoi une même marque peut y figurer deux fois. L'adresse complète est `https://api.sealtrust.io/v1/partner-portal/me`. La même route existe sans le préfixe `/v1`, et c'est la forme `/v1` qui est recommandée pour une nouvelle intégration. C'est l'appel à faire au démarrage de votre intégration. Il vous dit sur quelles marques vous avez le droit d'agir. Les autres points d'entrée du portail partenaire refusent tout produit qui appartient à une marque absente de cette liste. > [!INFO] Le portail partenaire est une surface distincte de l'API partenaire à clef > L'API partenaire à clef, sous `/v1/partner/...`, s'authentifie avec une clef > `st_live_...` et sert aux systèmes d'une marque. Le portail partenaire, sous > `/v1/partner-portal/...`, s'authentifie avec la session d'un compte de > réparateur ou de recycleur. Une clef d'API ne donne aucun accès à ce point > d'entrée. ## Autorisation Session d'un compte partenaire. Aucun droit de clef d'API n'intervient ici. Le compte doit avoir le rôle `repairer` (réparateur) ou `recycler` (recycleur). Un compte client ou un compte d'équipe de marque reçoit un 403, avec le message `Partner account required (repairer or recycler)`. Une clef d'API `st_live_...` placée dans `Authorization: Bearer` reçoit elle aussi un 403, avec un autre message, `Token invalide` : le portail ne la lit jamais comme un jeton de session. Deux façons de présenter la session, au choix. | Façon | Quand l'utiliser | | --- | --- | | En-tête `Authorization: Bearer ` | Appel de serveur à serveur, script, application mobile. C'est la forme utilisée dans les exemples ci-dessous. | | Cookie de session `access_token` | Navigateur, une fois connecté au portail. La connexion pose ce cookie, en `HttpOnly`. | Vous obtenez un jeton en appelant `POST /v1/auth/login` avec un corps au format formulaire, champs `username` et `password`. La réponse contient `access_token`, `refresh_token`, `token_type` et `role`. Le jeton d'accès vaut 60 minutes, le jeton de renouvellement vaut 7 jours. ```bash printf 'Mot de passe : ' stty -echo; IFS= read -r MOT_DE_PASSE; stty echo; echo printf '%s' "$MOT_DE_PASSE" | curl -s -X POST https://api.sealtrust.io/v1/auth/login \ -d "username=reparateur@exemple-sas.test" \ --data-urlencode "password@-" ``` Le mot de passe est lu en clavier masqué et transmis à `curl` par l'entrée standard. Ne l'écrivez pas directement sur la ligne de commande : il resterait dans l'historique de votre terminal et serait lisible dans la liste des processus de la machine pendant l'appel. Un appel fait depuis un navigateur avec le cookie de session doit venir d'une origine que nous autorisons, celle de la console. Un appel de serveur à serveur qui porte le jeton dans `Authorization` est accepté sans condition d'origine. ## Plafond d'appels Un plafond d'appels s'applique à ce point d'entrée. Il est réglé pour l'usage normal du portail, où vous cherchez un produit puis enregistrez une intervention. Au-delà, l'API répond 429. Le refus porte un en-tête `Retry-After` qui donne le nombre de secondes à attendre. Attendez ce délai, puis rappelez. Le plafond couvre l'ensemble du portail partenaire. Alterner entre les points d'entrée ne vous redonne donc pas de marge. Espacez vos appels au lieu de les envoyer en rafale. La valeur du plafond n'est pas un engagement et peut changer sans préavis. N'inscrivez aucun seuil en dur dans votre code, appuyez-vous sur `Retry-After`. Ce point d'entrée ne consomme aucun quota de produits et aucun quota journalier de clef d'API. ## Paramètres de chemin et de requête Ce point d'entrée n'accepte aucun paramètre de chemin ni de requête. ## Corps de la requête Aucun. C'est une requête `GET` et elle ne lit aucun corps. ## Requête d'exemple Le jeton montré ici est faux et sert d'exemple. Remplacez-le par le jeton d'accès que la connexion vous a rendu. :::onglets ```bash title="curl" curl -i https://api.sealtrust.io/v1/partner-portal/me \ -H "Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.0000000000000000000000000000.0000000000000000000000000000" ``` ```typescript const response = await fetch( "https://api.sealtrust.io/v1/partner-portal/me", { method: "GET", headers: { Authorization: "Bearer eyJhbGciOiJIUzI1NiJ9.0000000000000000000000000000.0000000000000000000000000000", }, }, ); console.log(response.status); console.log(await response.json()); ``` ```python import requests response = requests.get( "https://api.sealtrust.io/v1/partner-portal/me", headers={ "Authorization": ( "Bearer eyJhbGciOiJIUzI1NiJ9" ".0000000000000000000000000000" ".0000000000000000000000000000" ), }, timeout=30, ) print(response.status_code) print(response.json()) ``` ::: > [!INFO] Le SDK TypeScript ne couvre pas le portail partenaire > Le paquet `@sealtrust-io/sdk` expose la frappe en lot, la vérification et les > abonnements aux notifications. Les points d'entrée du portail partenaire > s'appellent en HTTP direct, comme ci-dessus. ## Réponse d'exemple Code HTTP 200. Un compte de réparateur accrédité par deux marques, dont l'une lui reconnaît aussi le métier de recycleur. ```json { "id": 128, "email": "reparateur@exemple-sas.test", "name": "Camille Exemple", "partner_type": "repairer", "brands": [ { "brand_id": 42, "brand_name": "Exemple SAS", "partner_type": "repairer", "status": "active" }, { "brand_id": 42, "brand_name": "Exemple SAS", "partner_type": "recycler", "status": "active" }, { "brand_id": 57, "brand_name": "Atelier Exemple", "partner_type": "repairer", "status": "active" } ] } ``` Code HTTP 200 également pour un compte partenaire qu'aucune marque n'a encore accrédité, ou dont les marques ont toutes retiré leur accréditation. La liste est vide, et l'appel ne renvoie pas d'erreur. ```json { "id": 128, "email": "reparateur@exemple-sas.test", "name": "Camille Exemple", "partner_type": "repairer", "brands": [] } ``` ### Les champs de la réponse | Champ | Type | Description | | --- | --- | --- | | `id` | `integer` | Identifiant de votre compte partenaire. | | `email` | `string` | Adresse électronique de votre compte. | | `name` | `string` ou `null` | Prénom et nom réunis, séparés par une espace. Vaut `null` quand les deux sont vides. | | `partner_type` | `string` | Le rôle de votre compte : `repairer` ou `recycler`. | | `brands` | `array` | Une entrée par accréditation active. Vide si vous n'en avez aucune. | Chaque entrée de `brands`. | Champ | Type | Description | | --- | --- | --- | | `brand_id` | `integer` | Identifiant de la marque. C'est cette valeur que vous retrouvez dans les interventions que vous enregistrez. | | `brand_name` | `string` ou `null` | Nom de la marque. Le modèle de réponse déclare ce champ nullable : prévoyez la valeur `null` dans votre code et repliez sur `brand_id` pour l'affichage. | | `partner_type` | `string` | Le métier que cette marque vous reconnaît : `repairer` ou `recycler`. | | `status` | `string` | Toujours `active`. Une accréditation retirée disparaît de la liste. | ### Deux points de lecture qui trompent souvent Une marque peut apparaître deux fois. Une accréditation porte sur un couple marque et métier. Une marque qui vous reconnaît à la fois réparateur et recycleur produit deux entrées avec le même `brand_id`. Le `partner_type` de la racine et celui d'une entrée de `brands` ne disent pas la même chose. Celui de la racine est le rôle de votre compte. Celui d'une entrée est le métier reconnu par cette marque précise. Fiez-vous à celui de l'entrée pour savoir ce que vous pouvez enregistrer chez une marque donnée. ### Ce que ce point d'entrée ne dit pas La liste des types d'intervention que vous avez le droit d'enregistrer n'est pas ici. Elle dépend du produit et de sa marque. Vous la lisez dans le champ `allowed_event_types` de `GET /v1/partner-portal/products/{identifier}`. ## Erreurs | Code | Condition | Que faire | | --- | --- | --- | | 401 | Vous ne présentez aucun jeton : ni en-tête `Authorization`, ni cookie de session. Message `Not authenticated`, en-tête `WWW-Authenticate: Bearer`. | Connectez-vous, puis rappelez avec `Authorization: Bearer `. | | 401 | Vous présentez un jeton qui n'est pas un jeton de session, par exemple un jeton de confirmation d'adresse ou de réinitialisation de mot de passe. Message `Invalid token`. | Utilisez le champ `access_token` rendu par la connexion, et lui seul. | | 401 | Votre connexion s'est arrêtée à l'étape de double authentification. Message `MFA verification required`. | Terminez la double authentification, puis rappelez avec le jeton obtenu à la fin. | | 401 | Une déconnexion ou un changement de mot de passe a révoqué le jeton. Message `Token has been revoked`. | Reconnectez-vous. Le jeton précédent ne redeviendra pas valable. | | 401 | Le jeton ne porte aucune adresse électronique. Message `Invalid token: missing email`. | Reconnectez-vous pour obtenir un jeton complet. | | 401 | Votre compte n'est plus actif. Message `Account disabled`. | Le jeton reste refusé tant que le compte n'a pas été réactivé. Demandez sa réactivation à votre contact chez la marque. | | 401 | Une panne imprévue interrompt la lecture du jeton. Message `Invalid JWT token`. | Réessayez. Si le refus dure, reconnectez-vous. | | 403 | Votre jeton est illisible, expiré, ou signé par autre chose. Message `Token invalide`. | Renouvelez la session. Un jeton d'accès vaut 60 minutes. | | 403 | Vous présentez une clef d'API `st_live_...` à la place d'un jeton de session. Message `Token invalide`. | Le portail partenaire n'accepte que la session d'un compte. Gardez vos clefs d'API pour les chemins `/v1/partner/...`. | | 403 | Votre compte n'est pas un compte partenaire : compte client, compte d'équipe de marque. Message `Partner account required (repairer or recycler)`. | Demandez un compte de réparateur ou de recycleur à la marque qui vous accrédite. | | 403 | Votre requête porte un `Origin` ou un `Referer` absent de la liste des origines autorisées, et elle n'a pas d'en-tête `Authorization: Bearer`. Message `Forbidden origin`. | Appelez depuis la console, ou faites l'appel de serveur à serveur en mettant le jeton dans `Authorization: Bearer`. | | 403 | Votre requête porte le cookie de session `access_token` sans aucun `Origin` ni `Referer`. Message `Origin or Referer header required`. | Laissez le navigateur poser l'en-tête `Origin`, ou faites l'appel de serveur à serveur en mettant le jeton dans `Authorization: Bearer`. | | 404 | Le compte désigné par le jeton n'existe plus. Message `User not found`. | Le compte a été supprimé. Contactez la marque qui vous avait accrédité. | | 429 | Vous avez dépassé le plafond d'appels. La réponse porte un en-tête `Retry-After`. | Attendez le nombre de secondes indiqué par `Retry-After`, puis rappelez. Le plafond couvre tout le portail partenaire, espacez donc l'ensemble de vos appels. | Deux refus visent le jeton et se distinguent par le code HTTP et par le message. Le 403 `Token invalide` vise le jeton lui-même, illisible ou expiré. Le 401 `Invalid token` vise un jeton lisible dont le type n'est pas celui d'une session. Déclenchez votre renouvellement de session sur les deux. Un compte partenaire sans aucune accréditation active reçoit un 200 avec une liste vide. Le 403 `Aucune accréditation active` que rendent `GET /v1/partner-portal/products/{identifier}` et `POST /v1/partner-portal/interventions` n'existe pas ici. ## Voir aussi - [`GET /partner-portal/products/{identifier}`](/reference/get-partner-portal-products/), retrouver un produit d'une marque qui vous a accrédité. - [`POST /partner-portal/interventions`](/reference/post-partner-portal-interventions/), enregistrer une intervention sur un produit. - [`GET /partner-portal/interventions`](/reference/get-partner-portal-interventions/), lister les interventions que votre compte a enregistrées.