Applications

An application represents a product or service you are building with Bulwark. Each workspace can contain multiple applications — for example, a web app, a mobile app, and an admin portal — all managed from a single dashboard.

Unified identity (Model B)

Users belong to the workspace, not to individual applications. A single user account works across every application in the workspace without re-registration.

This is the same model Google uses: one Google account gives you access to Gmail, YouTube, Drive, and every other Google product. In Bulwark, one user account gives your customers access to every application in your workspace.

What this means in practice:

  • A user who signs up through your web app can immediately sign in to your mobile app
  • Password resets, MFA enrollment, and profile changes apply everywhere
  • You manage one user directory, not one per application

Applications as configuration scopes

While identity is shared across the workspace, each application maintains its own configuration:

| Setting | Description | |---------|-------------| | API keys | Separate publishable key (pk_) and secret key (sk_) per application | | Branding | Logo, primary color, background color, and display name for hosted login pages | | Custom domain | Optional vanity domain for the hosted login page (e.g., auth.yourapp.com) | | Auth settings | Which authentication methods are enabled (password, magic link, social providers) | | Hosted login page | A dedicated login/signup page branded to the application | | Webhook endpoints | Application-specific webhook URLs for auth events | | Redirect URIs | Allowed callback URLs after authentication |

This means your marketing site can use magic-link-only authentication while your admin portal requires password plus MFA — all within the same workspace.

App-scoped tracking

Sessions and audit events are tagged with the originating application's ID. This lets you:

  • Filter dashboard views to a single application
  • See which application a user authenticated through
  • Track sign-up and sign-in volume per application
  • Review audit logs scoped to a specific application

Every session object includes an application_id field:

{
  "id": "sess_01j...",
  "user_id": "usr_01j...",
  "application_id": "app_01j...",
  "created_at": "2026-03-20T14:30:00Z",
  "ip_address": "203.0.113.42",
  "user_agent": "Mozilla/5.0 ..."
}

App switcher

In the dashboard, use the app switcher in the top navigation bar to select which application you are viewing. When you select an application:

  • Session lists filter to that application
  • Audit logs filter to that application
  • Analytics display data for that application only
  • Settings pages show that application's configuration

The app switcher also provides quick access to create new applications.

Creating applications

Via the dashboard

  1. Open the app switcher in the top navigation bar
  2. Click Create application
  3. Enter a name and select an environment (development or production)
  4. Your new application is created with a publishable key and secret key

Via the API

POST /api/v1/settings/applications
Authorization: Bearer <admin-token>
X-Bulwark-Tenant: <tenant-id>
Content-Type: application/json

{
  "name": "Mobile App",
  "environment": "production"
}

Response

{
  "id": "app_01j...",
  "name": "Mobile App",
  "environment": "production",
  "publishable_key": "pk_live_...",
  "secret_key": "sk_live_...",
  "created_at": "2026-03-20T10:00:00Z"
}

The secret key is shown once in the response. Store it in a secrets manager or environment variable immediately. It cannot be retrieved again — only rotated.

Environments

Each application has an environment that determines key prefixes and behavioral defaults:

| Environment | Publishable key prefix | Secret key prefix | Behavior | |-------------|----------------------|-------------------|----------| | development | pk_test_ | sk_test_ | Relaxed rate limits, test data isolation, localhost allowed in redirect URIs | | production | pk_live_ | sk_live_ | Production rate limits, strict redirect URI validation, real user data |

Create a development application for local development and testing, and a separate production application for your live service. They share the same user directory but operate with different keys and safety defaults.

Next steps