Nimriz

Auth model

How to call Nimriz APIs safely from trusted backends without exposing sensitive credentials.

Auth model

Nimriz is designed so your clients stay lightweight and sensitive credentials stay server-side.

Key principle

  • Never ship Supabase service-role keys to the browser.
  • If you’re building a dashboard or internal tool, call Nimriz APIs from your server (or from a trusted backend runtime) and authenticate users there.

Organization and workspace scope

Nimriz can now place an organization above one or more workspaces, but existing machine contracts stay workspace-scoped.

  • dashboard sessions can carry both an active organization and an active workspace
  • browser-authenticated users may explicitly switch organization and workspace context through the dashboard shell
  • workspace-targeted operational actions still resolve against the active workspace
  • existing integration contracts still keep account_id as the workspace key

That means org rollout does not replace the current workspace-owned API key, callback, analytics, or webhook contracts.

Recommended patterns

1) Server-side control plane calls (recommended)

Use your backend to call the Nimriz control plane endpoints (e.g. shorten, check slug). Store the returned short_url in your system.

2) Browser calls (limited / not recommended)

Browser calls are only appropriate when the endpoint is explicitly designed for public, low-trust usage and protected by strict quotas/rate limits and policy checks.

What Nimriz enforces server-side

  • Destination validation (blocked schemes like javascript: / data: / file:).
  • Reserved slugs on first-party domains.
  • Domain-bound uniqueness: uniqueness is defined by (domain_id, short_code).
  • Expiration policies and reactivation rules (tier/policy-driven).

Compatibility rule during org rollout

If you already integrate with Nimriz using workspace-scoped identifiers, keep doing that unless a specific API contract says otherwise.

  • account_id remains the operational workspace key
  • workspace API keys remain workspace-scoped
  • callback URLs that include :workspace_id remain workspace-scoped
  • org scope adds governance and billing context; it does not silently rewrite existing workspace contracts

Related guides