---
title: "Entra Assurance Resume"
method: POST
path: "/v1/auth/entra/email-assurance/resume"
tags: ["auth"]
---

# Entra Assurance Resume

`POST /v1/auth/entra/email-assurance/resume`

## Request

- Base URL: `https://api.patricia.app` (the document declares no server; this is the origin it was published from)
- URL: `https://api.patricia.app/v1/auth/entra/email-assurance/resume`
- Auth: none declared

Finish the sign-in the ceremony held open, and issue the session.

Unlike the callback, this answers JSON rather than a redirect: the browser is already on the
dashboard's waiting page by now, so there is nowhere to send it and no fragment to hide a
token pair in. It reaches ``AuthService`` only from ``mailbox_verified``, which only
:func:`entra_assurance_verify` can produce.

## Request body

- EntraAssuranceResumeRequest: The ceremony secret; resume also reads the optional first-time answer.
  - `resume_token` string, required
  - `first_time` boolean

## Response `200`

Successful Response

- TokenResponse: Access + refresh token pair. ``expires_in`` is the access-token lifetime (seconds).
  - `access_token` string, required
  - `refresh_token` string, required
  - `token_type` string
  - `expires_in` integer, required
  - `landing_hint` 'pending_invitation' | 'diverted_unknown_workspace': A non-authorization hint explaining WHY a session landed where it did. The dashboard reads it to show the right next step instead of a bare landing. It never grants access: the token's tenant claim (or its absence) is the sole authority. Two values, and they differ in whether the session has a workspace at all: ``PENDING_INVITATION`` lands TENANT-LESS — a returning user with at least one pending invitation and no active available home. It is NOT "only pending memberships": the branch is chosen on ``has_pending`` before the deactivated/unavailable fallback, so a user holding a pending invite alongside deactivated or unavailable ones lands here too. The SSO guard declines to mint an empty duplicate tenant, and the hint points them at accepting the invite / signing in from the connected workspace. ``DIVERTED_UNKNOWN_WORKSPACE`` lands WITH an active workspace — a returning user who signed in from a chat workspace Patricia does not know. The guard diverts them to their existing primary workspace rather than minting a second one, and the hint is what lets the dashboard say so and offer a deliberate way to create a separate workspace instead of failing silently.
  - `decision_key` string, nullable

## Other responses

- `422`: Validation Error

---

[API](https://skmtc.dev/patricia/apis/patricia-api.md) · [All operations](https://skmtc.dev/patricia/apis/patricia-api/llms.txt) · [OpenAPI document](https://skmtc.dev/patricia/apis/patricia-api/revisions/0dfb44495ea1?raw)