Registry Access & License

Dayflow Scheduler uses two separate credentials, and they are not interchangeable:

Credential	What it does	Where it lives
Registry token	Authorizes `npm install` against the private registry	`.npmrc`, from a shell or CI secret
License key	Activates the component in the browser at runtime	Your application startup code

The registry token is a download credential. Keep it in your local shell or CI secret store and never expose it through a client-side environment variable. The license key is a signed activation token and is meant to reach the browser.

1. Configure Registry Access

Add the @dayflow-scheduler registry scope configuration to the .npmrc file at your project root:

.npmrc

@dayflow-scheduler:registry=https://gitlab.com/api/v4/projects/81887987/packages/npm/
//gitlab.com/api/v4/projects/81887987/packages/npm/:_authToken=${DAYFLOW_SCHEDULER_NPM_TOKEN}

Export your token variable in your shell or CI secret store before installing:

export DAYFLOW_SCHEDULER_NPM_TOKEN="your-scheduler-registry-token"
npm install @dayflow-scheduler/core @dayflow-scheduler/react

2. Provide the License Key

Choose one of the two approaches below based on how your app obtains the key.

Option A: Register Once at Startup

Use global registration when the key is fixed for the lifetime of the page. Call registerDayflowProLicense() before your framework renders:

src/main.tsx (Vite)

import { registerDayflowProLicense } from '@dayflow-pro/license';

const token = import.meta.env.VITE_DAYFLOW_LICENSE_TOKEN;

if (!token) {
  throw new Error('Missing VITE_DAYFLOW_LICENSE_TOKEN');
}

registerDayflowProLicense({ token });

// Render React, Vue, Angular, or Svelte after registration.

For Next.js client code, use a client-exposed variable such as process.env.NEXT_PUBLIC_DAYFLOW_LICENSE_TOKEN.

Once registered, the scheduler component and every plugin read the license automatically; you can omit the license prop everywhere; global registration is not reactive, so it must happen before the first render.

Option B: Pass the License Explicitly

Use an explicit config for runtime license entry, account switching, multi-tenant apps, or tokens restored from browser storage:

import type { PackageLicenseConfig } from '@dayflow-pro/license';

const license: PackageLicenseConfig = {
  token,
  onTokenRefresh: nextToken => {
    localStorage.setItem('dayflow-license', nextToken);
  },
};

<DayflowScheduler app={app} license={license} />;

Plugins accept the same object:

createDragPlugin({ license });
createSchedulerKeyboardShortcutsPlugin({ license });

An explicit license overrides the globally registered one for that component or plugin.

PackageLicenseConfig

Property	Type	Required	Description
`token`	`string`	Required	The signed license key.
`onTokenRefresh`	`(nextToken: string) => void`	Optional	Called when the server returns a rotated token. Persist it.
`endpoint`	`string`	Optional	Override the verification endpoint. Most apps should omit this.
`headers`	`Record<string, string>`	Optional	Extra headers sent with the verification request.
`requestInit`	`RequestInit`	Optional	Extra `fetch` options for the verification request.
`fetcher`	`typeof fetch`	Optional	Custom fetch implementation, e.g. for proxying through your own backend.

3. Verify the Setup

Render the scheduler. If the license resolves, you see the timeline. If it does not, the component renders a status message in place of the scheduler instead of throwing, so a bad key never takes the surrounding page down.

Troubleshooting

`npm install` returns 401 or 404

Confirm .npmrc contains @dayflow-scheduler scope entry and that DAYFLOW_SCHEDULER_NPM_TOKEN is exported in the shell or CI job running the install.

The scheduler renders a license message instead of the timeline

For global registration, confirm registerDayflowProLicense() runs before the first render; a call inside a component body is usually too late. For explicit configuration, confirm the license prop reaches DayflowScheduler and every plugin factory.

The license works locally but not in production

The verification request runs in the browser. Confirm the token is exposed through a client-visible variable (VITE_*, NEXT_PUBLIC_*) and that your build actually inlined it, and that your CSP allows requests to the verification endpoint.

Getting Started: installation and first scheduler.
DayflowScheduler: the license prop.
Plugins Overview: plugins take the same license option.

On this page