Laravel Integrations Laravel Package

Product Decisions This Supports

• Build vs. buy for integration plumbing. The package owns the boring-but-risky parts of third-party connectivity: per-provider credential storage and encryption, credential rotation, health/status tracking after each request, and typed metadata. That is usually weeks of work to build correctly and is rarely a differentiator, so it is a good candidate to buy (adopt) rather than build.
• Scope of the integrations roadmap. Because credentials and metadata are modeled per-integration with an APP_PREVIOUS_KEYS-aware encryption path, you can put "connect your own provider account" and "rotate keys without downtime" on the roadmap with known effort, rather than as research spikes.
• Security and compliance decisions. Encryption-at-rest of credentials and a documented key-rotation path (old keys via APP_PREVIOUS_KEYS, re-encrypted with the current APP_KEY on next save) give you concrete answers for security reviews and customer questionnaires without a bespoke design.
• Scaling decisions for high-volume integrations. 6.5.1 removes write amplification: previously every successful request triggered recordSuccess(), and reading credentials/metadata as Data classes made Eloquent treat the columns as dirty, so each request rewrote them and took a row lock. Each write is now skipped when values are unchanged (JSON-compared, whitespace/key-order insensitive). This turns "how many integrations can we run against one database before lock timeouts" from an unknown into a bounded, testable number — relevant to whether you raise per-tenant integration limits or run integrations in a separate database.
• Decision on where integrations run. If your product polls or syncs on every request, this fix materially lowers contention; it supports keeping integrations on the primary database at moderate scale instead of pre-emptively splitting them out.
• Use cases unlocked: multi-provider OAuth/API-key connections per tenant, credential rotation on a schedule, health dashboards and alerting from recorded success state, and typed per-provider metadata without ad-hoc JSON handling.

When to Consider This Package

Adopt it when:

• Your product connects tenants to multiple third-party providers and you need consistent storage, encryption, and health state across them.
• You need encrypted credentials with a rotation story (APP_PREVIOUS_KEYS, re-encryption with the current APP_KEY) rather than a single hard-coded token in config.
• You want per-integration health signals (success recording after each request) to drive alerting or UI status.
• You are on a supported Laravel version and are comfortable with the package's provider abstraction (credentialDataClass(), metadataDataClass()) shaping your models.
• You care about database lock behavior at request rates — 6.5.1 is effectively a performance fix, so upgrade and confirm it before you scale polling/sync frequency.

Look elsewhere or build thin yourself when:

• You have one integration with a static API key — the abstraction costs more than it saves.
• You need a workflow/orchestration engine, retries, queues, or rate-limit management at the request layer; this package manages integration state, not job execution.
• You require provider-agnostic field-level audit history of credential changes — you will need to add that.
• You cannot take patch upgrades promptly: the write-amplification fix matters most precisely in the high-request-rate scenarios where lock timeouts are already painful, so treat staying current as a supportability requirement.
• Your data layer is not a JSON-column database with the semantics described (the metadata comparison fix targets MySQL-style JSON normalization); verify behavior on your engine.

How to Pitch It (Stakeholders)

To executives: We need every customer to connect their own third-party accounts. This package provides that connective tissue out of the box — encrypted credentials, key rotation, and per-integration health — so we build product features instead of plumbing. The 6.5.1 release is a maintenance patch, not a feature, but it removes needless database writes on every successful provider call; that directly reduces lock contention and the risk of timeouts as integration volume grows. Low-risk upgrade, no schema or API changes to coordinate.

To engineering: 6.5.1 fixes a real defect: with a credentialDataClass() set, reading $integration->credentials marked the encrypted column dirty (ciphertext comparison), and recordSuccess() fires on every successful request — so every request rewrote the row and held a lock. Same story for metadata on MySQL, where JSON normalization made round-tripped values compare unequal. Both casts now compare decoded JSON, and credentials decryptable only by an APP_PREVIOUS_KEYS key are intentionally treated as changed once so they get re-encrypted under the current APP_KEY. Patch-level, no migrations. Upgrade, then verify: no write on unchanged saves, one write on legacy-key credentials, and reduced lock wait times under load.