Skip to content

feat: accept-invite request/response contract for volunteer account linking #212

Description

@arturasmckwcz

Why

Part of the epic: need4deed-org/be#922 — inviting existing Volunteer rows (people who
submitted the public volunteer form but never created a login) to register as
a User with role: VOLUNTEER.

Backend will mint an invite JWT (type: "invite") tied to a pre-created,
inactive User row, and email a link. The frontend needs a page where the
invited person sets a password; that page calls a new backend endpoint. This
issue defines that endpoint's request/response contract in the SDK, since per
org convention (shared-rules.md) the SDK is the source of truth for the API
surface and must be published before be/fe consume it.

Scope

Add to src/types/api/ (follow existing file/naming conventions — check
whether an auth.ts file already exists for auth-related bodies, e.g.
password-reset, before deciding where this lives):

  • An accept-invite request body type, e.g. ApiAcceptInviteBody
    { token: string; password: string; confirmPassword: string }. Match the
    field naming/casing of whatever existing password-reset body type already
    exists in the SDK exactly (don't invent new naming for the same concept).
  • A response type — likely reuse ApiUserGet if the endpoint logs the person
    in / returns the activated account. Confirm against whatever be actually
    returns once its issue below is scoped.
  • Export the new type(s) from src/types/api/index.ts.

Open questions to resolve with the be dev during TODO review

  • Final endpoint path/method chosen in <BE_INVITE_ISSUE_URL> (extending
    POST /auth/password-reset vs a new POST /auth/accept-invite) — confirm
    before finalizing type names.
  • Whether a new Endpoint constant should be added to
    src/constants/endpoints.ts for consistency with the existing
    Endpoint.REGISTER.

Acceptance criteria

  • New type(s) added and exported from src/types/api/index.ts
  • Version published to npm (automatic on merge to main via
    .github/workflows/publish.yml)
  • be/fe issues below can pin the new published version

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions