Laravel Invite Only Laravel Package

Getting Started

1. Install with composer require offload-project/laravel-invite-only.
2. Publish package assets: config, migrations, language files, and—since v2.6.0—invitation email views/templates. Use the package’s vendor:publish tags/provider output to discover exact tags, then publish only what you need.
3. Run migrations and review config/invite-only.php for invite lifetime, code length/format, registration route, mail settings, and model bindings.
4. Add the package’s invite-aware trait to your User model if required by the docs, and ensure your registration flow validates an invite before creating a user.

First use case: an admin generates an invitation for an email address, the package sends an invitation email containing a code/link, and registration is blocked unless a valid, unused, unexpired invite is supplied.

Implementation Patterns

• Admin invite workflow: create invites from an admin panel or artisan command, optionally queue invitation emails, and expose resend/revoke actions. Keep invite creation in a small service or action class so web, API, and console paths share the same rules.
• Registration gating: validate the invite code/link at the start of registration, bind the invite to the email being registered, and mark it accepted only after successful user creation. Prefer a database transaction around acceptance and user creation.
• Custom email branding (v2.6.0): publish the invitation email views/templates instead of relying only on language files. Override subject lines, copy, CTA links, and layout in your app’s resources while leaving vendor files untouched.
• Localization: keep using published lang files for translated copy, and use published email templates for layout/branding. Avoid editing files under vendor/.
• Queued delivery: if invitation emails are queued, confirm the package notification/mailable respects your queue configuration. Use Mail::fake() in tests to assert invite emails are sent with the correct invite and recipient.
• Integration points: wrap invite checks in middleware or a form request; dispatch domain events after invite creation/acceptance if you need audit logs, CRM sync, or onboarding automation.

Gotchas and Tips

• Publishing is not automatic: v2.6.0 makes email templates publishable, but existing apps must republish to get customizable email views. Check whether your published overrides need updating after package upgrades.
• Watch publish tags: use the package’s documented vendor:publish tags/provider rather than guessing; publishing “all” assets can overwrite customised config or views.
• Invite expiry and reuse: enforce single-use and expiry checks in the same place as registration validation. Race conditions can allow double acceptance—use transactions and database constraints where possible.
• Email matching: decide whether an invite is tied to an email address. If so, reject registration attempts using a different email even when the code is valid.
• Config caching: after changing invite config or publishing assets in deployed environments, run php artisan config:clear/config:cache and clear view caches as appropriate.
• Testing: cover expired invites, already-accepted invites, invalid codes, mismatched emails, and queued mail delivery. Use factories for invites where the package provides them, or create test helpers.
• Extension points: customise the invitation notification/mailable and email views first; only override package classes if you need different invite generation, validation, or persistence behaviour.