Alp Crm Laravel Package

Getting Started

The README is now the canonical entry point — it doubles as the Statamic Marketplace listing copy, so it is written to be read end-to-end before you run composer require. Read it in the order it is laid out: first-run setup → scheduler and queue configuration → portal linking → API and webhook examples → integrations → upgrades → troubleshooting. Skipping ahead to the API section is the most common way to end up with a half-configured install.

Minimal path:

1. Install the addon and complete the documented first-run setup (published config, any migrations, and whatever bootstrap step the guide defines). Do this on a scratch environment first — first-run setup is the step most likely to differ from your assumptions.
2. Configure the scheduler and queue before enabling anything that dispatches jobs. These are documented as setup prerequisites, not post-install tuning, which tells you the addon assumes an async pipeline is live.
3. Link one portal account and confirm the round trip works.
4. Only then add integrations and webhook consumers.

First real use case: push a single record through the entire loop in staging — create it in the Statamic CP, link it to a portal user, observe the outbound webhook arrive at a request bin, and confirm the queued job drained. That one exercise validates setup, scheduler, queue, portal linking, and webhook delivery in a single pass, and it is far cheaper than discovering a broken queue worker in production.

Note on v2.1.1: this is a documentation-only release with no application behavior changes. If you are already on a 2.x version, nothing in your runtime changes; the only delta is that the operational guidance is now substantially better and worth re-reading if you installed from an older README.

Implementation Patterns

Treat the scheduler/queue section as production ops documentation, not setup trivia. Commit the schedule definition to source control, run workers under Supervisor or Horizon, and add a monitor on queue depth. Because the README documents both together, the addon likely has recurring work and deferred work — confirm both are running independently rather than assuming one implies the other.

Portal linking is a relationship, so model it explicitly. Mirror the README's linking flow rather than improvising: handle both the "link an existing account" and "invite/create" paths if the guide documents them, and decide up front what happens when a portal user is deleted or unlinked. Store the linkage on your user model side so you can query it without hitting the addon's internals.

Consume the API and webhooks as you would any third party. Version-pin your consumers, verify webhook signatures, use idempotency keys on inbound handlers, and never do real work inside the HTTP request — enqueue it. The README's API and webhook examples are copy-paste starting points; harden them before they reach production.

Onboard integrations one at a time. Each integration adds credentials and a failure mode. Wire one, verify it end-to-end with real traffic, then add the next. Keep credentials in .env and confirm the published config reads from env rather than hardcoding.

Use the upgrades section as a pre-flight checklist. Even for a docs-only release like this one, read it before composer update. Pin the addon version in composer.json so a routine update cannot silently pull a minor with behavior changes.

Gotchas and Tips

• A scheduler that isn't running fails silently. This is the most likely first-run problem given how prominent the scheduler section is. Verify the cron entry exists, run php artisan schedule:list, and confirm your scheduled tasks actually appear.
• The sync queue driver hides failures. Local development on sync will make a misconfigured job look fine; production won't. Test with a real worker and a real driver before you trust the pipeline.
• Webhook retries mean duplicate deliveries. Assume at-least-once delivery: make handlers idempotent, log raw payloads on receipt, and check whether signature verification depends on an env value that is easy to leave blank.
• Docs-only releases carry a specific risk: drift. There is no code to diff, so the README is now effectively your spec. If behavior and documentation disagree, trust the behavior and note the discrepancy — and re-read the troubleshooting section before filing an issue, since it is explicitly written to cover the common linkage and queue failures.
• Upgrade notes are the first thing to read, not the last. When a future release does change behavior, the upgrades section will be the only place the migration steps are recorded. Build the habit now.
• Extension points to prefer: published config, the documented events/webhooks, and the portal-linking surface. Those are the stable contracts the README commits to. Avoid patching anything under vendor/ — you'll lose it on the next update and you have no diff to help you reapply it.
• The troubleshooting section is a genuine asset. With the README now functioning as the operations guide for the Marketplace listing, expect it to be maintained as the primary support surface — check it before searching for third-party write-ups, which will likely lag behind.