Team And Invites

Hooksbase projects are backed by an organization-style membership model. Team management is a dashboard product flow — there are no public API routes for it. Everything below is done from the browser.

Membership model

A project team controls who can sign into the dashboard and operate the project. The dashboard exposes:

  • member listing
  • role updates
  • member removal
  • pending invitation listing
  • invitation cancellation
  • invitation re-notification

Hooksbase also prevents a few destructive mistakes:

  • you cannot remove the project owner
  • you cannot remove the last remaining member

Where this lives

Team management is entirely dashboard-first:

  • a project admin sends, cancels, and re-sends invitations from project settings
  • invited users receive an email with an accept link; clicking it opens a signed-in acceptance flow in the dashboard
  • members and roles are edited from the team section of project settings

Project API keys cannot manage team membership — this surface is not part of the Public API.

Invitation flow

The normal invite flow is:

  1. A project admin sends an invitation from the dashboard.
  2. Hooksbase creates a pending invitation linked to the project.
  3. If email is configured for the deployment, Hooksbase sends an invite email with an accept URL.
  4. The invited user opens the link, signs in (or signs up), and accepts the invitation.

Operational details that matter:

  • invite email delivery can be skipped or fail when email is not configured for the deployment
  • re-notify only works for still-pending invitations
  • cancellation removes the pending invite without changing active membership
  • if the deployment's email configuration changes later, a previously skipped invitation can start delivering on the next re-notify

Preview, accept, cancel, and notify

The invitation lifecycle is:

  1. Preview — the invite link lands on a preview page so the recipient can see which project they are joining before accepting.
  2. Accept — the recipient signs into their account to complete acceptance.
  3. Cancel — a project admin can cancel a pending invite if it should no longer be usable.
  4. Re-notify — a project admin can trigger a fresh invite email for a still-pending invitation.

Pending-state caveats:

  • the preview page never accepts the invite by itself
  • acceptance still requires a valid session for the invited user
  • if email is unconfigured, the invite object exists but the notification side-effect remains skipped until a re-notify succeeds

Common mistakes

  • Expecting invites to work without an email provider configured.
  • Assuming opening the invite preview page also accepts the invitation.
  • Removing the wrong member without realizing owner and last-member protections exist.
  • Treating a pending invite as active project access before the accept step completes.
  • Looking for team management in the Public API — it is a dashboard-only flow.

Was this page helpful?