Authentication

OwlFlow uses a dual-layered authentication model.

1. Partner Authentication (API Key)

All requests to the production and staging environments require a valid API key provided via the x-api-key header. This is enforced by the Google API Gateway.

x-api-key: YOUR_PARTNER_API_KEY

2. User Authentication (JWT)

For user-specific operations (viewing profile, applying to scholarships), you must provide a Bearer token obtained from the login or googleAuth mutations.

Obtaining a Token

mutation Login($input: LoginInput!) {
  auth {
    login(input: $input) {
      token
      expiresAt
    }
  }
}

Using the Token

Include the token in the Authorization header of your requests:

Authorization: Bearer <your_token_here>

Internal Session and Identity Bootstrap

The client contract is unchanged: applications send the OwlFlow JWT as a Bearer token and never send Laravel cookies.

For each authenticated request, OwlFlow:

1. verifies the JWT signature and reads its sub account id and jti session id;
2. resolves the jti to the existing Laravel session cookie through token storage, backed by Firestore in deployed environments;
3. uses the feature-flagged Core MySQL repository to bootstrap the account identity when owlflow-db-account-bootstrap is enabled;
4. falls back to Core's account-info endpoint when the database is unavailable.

A missing or soft-deleted database account is an authentication failure and does not fall back to Core. Raw Laravel cookie requests continue to validate through Core. The mapped Laravel session cookie is retained for downstream REST and JSON:API calls, so existing Core authorization and session behavior remain unchanged.