- Does darkin1/intercom support Laravel 9, 10, or 11?
- No. The package declares support for Laravel 5.x, 6.x, and 7.x only, and its last release was in May 2021. Running composer require against a Laravel 9, 10, or 11 application will almost certainly fail on the framework constraint, the pinned upstream Intercom SDK constraint, and likely a PHP ceiling as well. Making it work means forking and relaxing composer.json, which only buys you a wrapper around an SDK Intercom has itself deprecated.
- How do I install darkin1/intercom?
- Install it with composer require darkin1/intercom. On Laravel 5.5 and later the service provider and Intercom facade are auto-discovered, so no manual registration is required. After installing, publish the config file with php artisan vendor:publish and add your Intercom access token. Setup is genuinely a two-line job on a supported Laravel version.
- How do I configure the Intercom access token?
- The token lives in the package config file, typically read from an environment variable, so you set it in .env rather than committing it. The package does not provide per-tenant tokens or secrets-manager integration, so multi-tenant or rotated credentials are your responsibility. Verify the config is safe under php artisan config:cache before deploying.
- What features does darkin1/intercom actually provide?
- It is a thin service-provider wrapper around Intercom's official PHP SDK: a config file holding the API token, a container singleton, and an Intercom facade that proxies calls to the underlying client. In practice you can do whatever the SDK exposes, such as syncing users and companies, tracking events, tagging contacts, and managing conversations. It adds no domain logic, no sync engine, no webhook handling, and no identity-verification helper, so those are yours to build.
- Is darkin1/intercom actively maintained?
- No. The repository has roughly 15 stars, a single maintainer, and no release since May 2021, with no evidence of CVE response. Even a fork inherits a pinned, unmaintained upstream Intercom SDK on a fixed API version. Treat it as abandoned and plan accordingly rather than depending on future fixes.
- Does darkin1/intercom handle Intercom webhooks or Messenger identity verification?
- No. The package does not register a webhook route, so inbound webhook handling and signature verification are entirely on you. It also does not expose the user_hash HMAC-SHA256 helper needed to enable Identity Verification in the Intercom Messenger. Both are common gaps that significantly reduce the package's value.
- How do I test or mock code that uses the Intercom facade?
- Because the package binds a global facade backed by a container singleton, mocking usually means Intercom::shouldReceive in your tests. There is no PSR-18 client injection, so you cannot swap in a fake transport cleanly, and static calls tend to leak across controllers and queued jobs. If testability matters, wrap the facade behind your own interface such as a CrmGateway and bind a fake implementation in tests.
- Which intercom/intercom-php version does darkin1/intercom pin?
- You need to check this yourself, because it determines whether the SDK speaks the Intercom API version you are contracted to. Run composer show darkin1/intercom and inspect its composer.json constraints, then compare against the upstream SDK changelog. Expect an older pinned release, and treat API drift over time as a real risk. Also confirm that SDK and its PHP constraint match your runtime.
- What are the alternatives to darkin1/intercom?
- The honest comparison is this package versus roughly 200 lines of your own code. A small in-house adapter over Laravel's HTTP client, or directly over the official SDK, gives you dependency injection, retries, logging, and PSR-18 testability without an unowned dependency. Other community Laravel Intercom packages exist but tend to have the same facade-and-config shape and similar maintenance risk, so check their release history first.
- Is darkin1/intercom safe to use in production?
- Only as a short-term stopgap in a legacy Laravel 5.8 to 7 application that is still in service. Risks include an end-of-life framework ceiling that blocks PHP 8.1 and current security patching, an unmaintained upstream SDK, and an unmaintained code path touching customer PII. Rate limiting and retry behaviour on 429 and 5xx responses depends entirely on the vendor SDK, so confirm that before going live. For Laravel 8 through 11, build the adapter instead.