Skip to main content
Core ships with a powerful Developer API that lets you integrate third-party systems, build external customer portals, and automate workflows — all using standard OAuth 2.0. Every resource available in the Core UI is exposed through the same API, so external applications can read, create, and update data with fine-grained permission control. You manage API access through App Clients — OAuth 2.0 clients that represent the external application or service connecting to Core. Each client gets its own credentials and permission set, keeping integrations isolated and auditable.

​
Required setup

The API uses Laravel Passport for OAuth2. Before the API is functional, you need to generate RSA encryption keys and store them in your environment. Run the following command to generate the keys and write them directly to your .env: 
php artisan core:passport-keys
This generates a PASSPORT_PRIVATE_KEY and PASSPORT_PUBLIC_KEY in your .env file. Storing the keys in the environment (rather than as files on disk) is required for cloud deployments where the filesystem is ephemeral.
Run this once per environment (local, staging, production). Use --force to regenerate existing keys. The command removes the key files from storage/ after writing them to .env.

​
Authentication flows

Two authentication flows are available:

Client Credentials

App-to-app authentication. The app client authenticates directly with its own identity and permissions. Best for integrations, automated systems, and admin APIs.

Authorization Code

User-authenticated OAuth. Users authorize the app via a consent screen, and the resulting token acts on their behalf. Best for external customer portals.

​
Managing app clients

App clients are managed in Developer → Apps. You need the manage_system permission to access this section.

​
Creating an app client

1

Open the Developer section

Navigate to Developer → Apps and click New app client.
2

Configure the client

Fill in the following fields:
  • Name — A human-readable name for the client (e.g. Schoolsoft Integration).
  • Description — Optional. Describes the purpose of this client.
  • Grant types — Select one or both:
    • Client credentials — For app-to-app authentication.
    • Authorization code — For user OAuth flows.
  • Redirect URIs — Required when using the authorization code grant. One URI per line.
3

Copy the client secret

After creation, you are redirected to the client’s detail page. Copy the client secret immediately — it is only shown once.
The client secret is hashed and cannot be retrieved after you leave this page. Store it securely (e.g. in a secrets manager or environment variable).

​
Assigning roles and permissions

For client credentials (app-to-app) flows, the app client’s own Spatie roles and permissions apply — not a user’s. You can configure these on the client’s Permissions tab. This lets you control exactly what data an integration can access, independent of any user account.

​
Revoking or deleting a client

  • Delete the client from the Danger zone section on its detail page. All access tokens are immediately invalidated.
  • Deleted clients are soft-deleted and can be recovered by a developer if needed.

​
Client credentials (client ID and secret)

Every app client has a Client ID (UUID) and a Client Secret (random string). These are used to obtain access tokens.
FieldDescription
Client IDUnique identifier for the client. Safe to expose publicly.
Client SecretUsed together with Client ID to authenticate. Keep secret.

​
Next steps