# GET /partner-portal/me

Read your partner profile and the list of brands that have accredited you. Partner account session, no API key right.

Source: https://docs.sealtrust.io/en/reference/get-partner-portal-me/

---

You read your partner profile and the list of brands that have accredited you,
with the trade recognized for each one. By the end of this page, you will know
how to present your session, what the response contains, and why the same brand
can appear in it twice.

The full address is `https://api.sealtrust.io/v1/partner-portal/me`. The same
route exists without the `/v1` prefix, and the `/v1` form is the one recommended
for a new integration.

This is the call to make when your integration starts up. It tells you which
brands you have the right to act on. The other partner portal endpoints refuse
any product that belongs to a brand missing from this list.

> [!INFO] The partner portal is a surface distinct from the key-based partner API
> The key-based partner API, under `/v1/partner/...`, authenticates with an
> `st_live_...` key and serves a brand's systems. The partner portal, under
> `/v1/partner-portal/...`, authenticates with the session of a repairer or
> recycler account. An API key gives no access at all to this endpoint.

## Authorization

Session of a partner account. No API key right comes into play here.

The account must have the `repairer` or `recycler` role. A customer account or a
brand team account receives a 403, with the message
`Partner account required (repairer or recycler)`. An `st_live_...` API key
placed in `Authorization: Bearer` also receives a 403, with a different message,
`Token invalide`: the portal never reads it as a session token.

Two ways to present the session, as you prefer.

| Way | When to use it |
| --- | --- |
| `Authorization: Bearer <token>` header | Server-to-server call, script, mobile application. This is the form used in the examples below. |
| `access_token` session cookie | Browser, once signed in to the portal. Signing in sets this cookie, as `HttpOnly`. |

You obtain a token by calling `POST /v1/auth/login` with a form-format body,
fields `username` and `password`. The response contains `access_token`,
`refresh_token`, `token_type` and `role`. The access token lasts 60 minutes, the
refresh token lasts 7 days.

```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@-"
```

The password is read with hidden input and passed to `curl` through standard
input. Do not write it directly on the command line: it would stay in your
terminal history and would be readable in the machine's process list during the
call.

A call made from a browser with the session cookie must come from an origin we
authorize, that of the console. A server-to-server call that carries the token
in `Authorization` is accepted with no condition on origin.

## Rate limit

A rate limit applies to this endpoint. It is set for normal use of the portal,
where you look up a product and then record an intervention.

Beyond it, the API answers 429. The refusal carries a `Retry-After` header that
gives the number of seconds to wait. Wait that long, then call again.

The limit covers the whole partner portal. Alternating between endpoints
therefore does not give you back any headroom. Space out your calls instead of
sending them in bursts.

The limit value is not a commitment and may change without notice. Hard-code no
threshold in your code, rely on `Retry-After`.

This endpoint consumes no product quota and no daily API key quota.

## Path and query parameters

This endpoint accepts no path or query parameter.

## Request body

None. This is a `GET` request and it reads no body.

## Example request

The token shown here is fake and serves as an example. Replace it with the
access token that signing in returned to you.

:::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] The TypeScript SDK does not cover the partner portal
> The `@sealtrust-io/sdk` package exposes batch minting, verification and
> notification subscriptions. The partner portal endpoints are called over plain
> HTTP, as above.

## Example response

HTTP code 200. A repairer account accredited by two brands, one of which also
recognizes it as a recycler.

```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"
    }
  ]
}
```

HTTP code 200 as well for a partner account that no brand has accredited yet, or
whose brands have all withdrawn their accreditation. The list is empty, and the
call does not return an error.

```json
{
  "id": 128,
  "email": "reparateur@exemple-sas.test",
  "name": "Camille Exemple",
  "partner_type": "repairer",
  "brands": []
}
```

### The fields of the response

| Field | Type | Description |
| --- | --- | --- |
| `id` | `integer` | Identifier of your partner account. |
| `email` | `string` | Email address of your account. |
| `name` | `string` or `null` | First name and last name joined, separated by a space. Is `null` when both are empty. |
| `partner_type` | `string` | Your account's role: `repairer` or `recycler`. |
| `brands` | `array` | One entry per active accreditation. Empty if you have none. |

Each entry of `brands`.

| Field | Type | Description |
| --- | --- | --- |
| `brand_id` | `integer` | Identifier of the brand. This is the value you find again in the interventions you record. |
| `brand_name` | `string` or `null` | Name of the brand. The response model declares this field nullable: plan for the value `null` in your code and fall back on `brand_id` for display. |
| `partner_type` | `string` | The trade this brand recognizes for you: `repairer` or `recycler`. |
| `status` | `string` | Always `active`. A withdrawn accreditation disappears from the list. |

### Two reading points that often mislead

A brand can appear twice. An accreditation covers a brand and trade pair. A
brand that recognizes you as both a repairer and a recycler produces two entries
with the same `brand_id`.

The `partner_type` at the root and the one in an entry of `brands` do not say
the same thing. The one at the root is your account's role. The one in an entry
is the trade recognized by that specific brand. Rely on the one in the entry to
know what you can record with a given brand.

### What this endpoint does not say

The list of intervention types you have the right to record is not here. It
depends on the product and its brand. You read it in the `allowed_event_types`
field of `GET /v1/partner-portal/products/{identifier}`.

## Errors

| Code | Condition | What to do |
| --- | --- | --- |
| 401 | You present no token: neither an `Authorization` header nor a session cookie. Message `Not authenticated`, header `WWW-Authenticate: Bearer`. | Sign in, then call again with `Authorization: Bearer <token>`. |
| 401 | You present a token that is not a session token, for example an address confirmation or password reset token. Message `Invalid token`. | Use the `access_token` field returned by signing in, and only that one. |
| 401 | Your sign-in stopped at the two-factor authentication step. Message `MFA verification required`. | Complete the two-factor authentication, then call again with the token obtained at the end. |
| 401 | A sign-out or a password change revoked the token. Message `Token has been revoked`. | Sign in again. The previous token will not become valid again. |
| 401 | The token carries no email address. Message `Invalid token: missing email`. | Sign in again to obtain a complete token. |
| 401 | Your account is no longer active. Message `Account disabled`. | The token stays refused until the account has been reactivated. Ask your contact at the brand to reactivate it. |
| 401 | An unforeseen failure interrupts the reading of the token. Message `Invalid JWT token`. | Try again. If the refusal lasts, sign in again. |
| 403 | Your token is unreadable, expired, or signed by something else. Message `Token invalide`. | Renew the session. An access token lasts 60 minutes. |
| 403 | You present an `st_live_...` API key instead of a session token. Message `Token invalide`. | The partner portal accepts only an account session. Keep your API keys for the `/v1/partner/...` paths. |
| 403 | Your account is not a partner account: customer account, brand team account. Message `Partner account required (repairer or recycler)`. | Ask the brand that accredits you for a repairer or recycler account. |
| 403 | Your request carries an `Origin` or a `Referer` missing from the list of authorized origins, and it has no `Authorization: Bearer` header. Message `Forbidden origin`. | Call from the console, or make the call server-to-server by putting the token in `Authorization: Bearer`. |
| 403 | Your request carries the `access_token` session cookie with no `Origin` and no `Referer`. Message `Origin or Referer header required`. | Let the browser set the `Origin` header, or make the call server-to-server by putting the token in `Authorization: Bearer`. |
| 404 | The account designated by the token no longer exists. Message `User not found`. | The account has been deleted. Contact the brand that had accredited you. |
| 429 | You have exceeded the rate limit. The response carries a `Retry-After` header. | Wait the number of seconds indicated by `Retry-After`, then call again. The limit covers the whole partner portal, so space out all of your calls. |

Two refusals target the token and are told apart by the HTTP code and by the
message. The 403 `Token invalide` targets the token itself, unreadable or
expired. The 401 `Invalid token` targets a readable token whose type is not that
of a session. Trigger your session renewal on both.

A partner account with no active accreditation receives a 200 with an empty
list. The 403 `Aucune accréditation active` returned by
`GET /v1/partner-portal/products/{identifier}` and
`POST /v1/partner-portal/interventions` does not exist here.

## See also

- [`GET /partner-portal/products/{identifier}`](/en/reference/get-partner-portal-products/),
  find a product of a brand that has accredited you.
- [`POST /partner-portal/interventions`](/en/reference/post-partner-portal-interventions/),
  record an intervention on a product.
- [`GET /partner-portal/interventions`](/en/reference/get-partner-portal-interventions/),
  list the interventions your account has recorded.
