Set up with your coding assistant
Give your assistant the context to connect BusinessMode to the app you already have. You stay in control of accounts, credentials, and live changes.
Before you paste
Open your application repository in a coding assistant that can read and edit its files. The prompt asks it to inspect your app, read the current HTTP documentation, and agree an implementation plan with you.
You will still need a BusinessMode account, a Project machine key, and a License configured for the capability you want to protect. Start in staging. Never paste API keys or other secrets into the conversation.
Help me integrate BusinessMode into this existing application.
First inspect the repository, framework, authentication, server routes and tests. Explain the smallest integration plan before changing code. Preserve unrelated work and the existing identity system. Do not assume you can create accounts, choose commercial terms or obtain credentials for me.
Read the current BusinessMode documentation before implementation:
- https://businessmode.io/docs/quickstart
- https://businessmode.io/docs/authentication
- https://businessmode.io/docs/idempotency
- https://businessmode.io/docs/errors
- https://businessmode.io/docs/api/create-machine-seat-assignment
- https://businessmode.io/docs/api/has-access
- https://businessmode.io/docs/guides/seat-management
Use the published HTTP contract, not guessed SDK methods. If the documentation is unavailable, tell me what is missing rather than inventing an API. Do not install @businessmode/sdk: it is currently private.
Before making any live request, ask me to confirm:
1. The target BusinessMode environment and API base URL. Use staging/test first. Production writes require my explicit approval.
2. The Project, Organization, Entitlement key and License we intend to use. I may need to create these in the BusinessMode app, with the right seats and validity dates.
3. The stable external user ID from my application's authenticated user. Do not substitute email or silently normalize IDs.
4. Which deliberate action should allocate a seat, and which application capability should be protected.
Have me create a Project machine API key in BusinessMode and place it in the application's server-only secret store or an ignored local environment file. Never ask me to paste a secret into chat. Never print secrets, commit them, put them in NEXT_PUBLIC_* variables or send them to a browser. Use BUSINESSMODE_API_URL, BUSINESSMODE_API_KEY and BUSINESSMODE_LICENSE_ID as suggested server-side names, adapted to the repository's conventions. A Developer JWT is not a substitute for a runtime machine key.
Implement a small server-side HTTP integration:
- POST {API_BASE_URL}/licenses/{licenseId}/assignments with Authorization: Bearer <machine key>, Content-Type: application/json, body {"externalUserId":"<authenticated stable ID>"}, and a retained Idempotency-Key.
- One idempotency key represents one logical assignment attempt. Persist/reuse the SAME key, path and body after an ambiguous network result. Do not generate a fresh key for every transport retry, or run an assignment mutation on every access check. Follow the actual documented error/recovery contract.
- GET {API_BASE_URL}/access with URL-encoded externalUserId and entitlementKey query parameters and the server-side machine key. Read the documented hasAccess result, not seat existence, billing state or a plan-name comparison.
- Get user identity from the trusted server authentication boundary. A caller-supplied user ID is not permission to check or grant somebody else's access.
- Enforce authorization on the server. Define a conservative, explicit unavailable/error response; an API timeout must not grant access. Follow documented retry guidance with bounded retries, never blind replay of non-idempotent mutations.
- Do not implement invitations, access codes, webhooks, billing or bulk operations unless we decide they are needed. Do not release/revoke existing customer access as part of setup.
Add tests using mocked HTTP responses for allowed access, denied access, unauthenticated users, capacity/conflict errors, transport ambiguity and idempotency-key reuse. Keep normal tests independent of live providers. Do not seed or reset a database, create remote infrastructure, buy anything or deploy without separate approval.
Run the relevant checks. Show me the changed files, non-secret environment-variable names, how to exercise the integration, and any remaining manual setup. Clearly distinguish mocked tests from a real, explicitly approved staging assignment/access check. Do not claim the integration is live until that check has actually passed.What it should build
A small server-side integration that assigns a seat when you intend to grant it, checks current feature access for an authenticated user, and includes mocked tests. It should not create infrastructure, change billing, or deploy on your behalf without permission.
Review the code and the reported test results. A passing mock is not proof of a live integration: finish with an explicitly approved staging assignment and access check.
Prefer doing it yourself? Follow the raw-HTTP Quickstart. For the underlying model, read Access decisions.