Woleet Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for third-party integrations. The package now exposes two credential surfaces — API_TOKEN for outbound calls to the vendor and CALLBACK_SECRET for verifying inbound callbacks — which means the integration is bidirectional. That is the threshold where hand-rolling your own HTTP client stops being cheap: you would otherwise be reimplementing signature verification, replay handling, and token plumbing in every service that touches this vendor.
• Feature scoping for webhook-driven workflows. CALLBACK_SECRET implies signed inbound events. This unlocks product features that are event-driven rather than poll-based (near-real-time status changes, async completion notifications, inbound sync triggers) at a lower infrastructure cost than polling. Worth deciding early whether your roadmap assumes push or pull, because it changes latency promises you make to customers.
• Credential architecture and multi-tenancy. Two static secrets suggest a single-tenant, env-var-configured integration. If the roadmap includes per-customer or per-workspace vendor accounts, this is a signal to plan a credentials abstraction (database-backed, encrypted) rather than shipping env-only config. Flag now; retrofit is expensive.
• Security and compliance roadmap inputs. Callback verification is a security control, not a feature. Its presence is a checklist item for SOC 2 / vendor security reviews and should be reflected in your threat model and onboarding documentation.
• Operational readiness decisions. Token and secret rotation, and what happens to in-flight callbacks during rotation, are product-visible: they determine whether you can promise zero-downtime credential rotation or must schedule maintenance.

Caveat for the reader: the release signal here is two configuration keys and nothing else — no changelog, no migration notes, no version constraints, no description of the signing algorithm. Treat the above as directional. The first real PM task is to get the package's README and changelog in front of engineering before committing roadmap items to it.

When to Consider This Package

Adopt when:

• You are integrating with a specific external vendor and do not want to own HTTP client code, retry logic, and callback signature verification in-house.
• Your application is already Laravel and you want configuration-driven credentials (API_TOKEN, CALLBACK_SECRET) rather than bespoke service classes.
• You need inbound callback verification as a first-class concern, and you would otherwise be verifying HMAC signatures by hand — a common source of subtle security bugs.
• Your credential model is one account per deployment (single-tenant). Env-var configuration is a good fit here and a poor fit for per-tenant credentials.

Look elsewhere or hold when:

• Multi-tenant credentials are required. Env-only secrets do not scale to N customer accounts; you will end up wrapping the package anyway.
• The release notes are the only documentation. Two bare variable names with no explanation of the signing scheme, expected header names, or replay protection is a documentation gap that translates directly into integration risk and support load. Ask for the README before adoption.
• Secret rotation is a hard requirement and the package offers no dual-secret or grace-period mechanism — you would be coupling your uptime to a manual, coordinated deploy.
• The vendor is not core to your product. A thin wrapper around one HTTP endpoint plus a signature check is often 100 lines of first-party code; a dependency earns its place only if the vendor's API surface is broad or volatile.
• PHP/Laravel version support is unstated. Unverified framework compatibility is a maintenance liability for a package that sits on your auth path.

How to Pitch It (Stakeholders)

To executives: This package handles both directions of our integration with the vendor — authenticating our outbound requests and cryptographically verifying the callbacks they send us. The alternative is building and maintaining that ourselves, including the security-sensitive signature verification. It reduces time-to-market for event-driven features and removes a class of security bug from our own codebase. The cost is one dependency and two secrets to manage.

To engineering: Configuration is two env vars — API_TOKEN for outbound auth, CALLBACK_SECRET for verifying inbound callbacks. Before we commit, we need from the package maintainers: the signing algorithm and header contract, replay-protection behavior, supported Laravel/PHP versions, and whether rotation supports overlapping secrets. If we are single-tenant and the vendor API is stable, this is a reasonable buy; if we need per-tenant credentials, plan on a wrapper layer from day one.

Recommendation: Proceed to a timeboxed technical spike — not a roadmap commitment. The release gives us enough to know the integration shape but not enough to assess fit, and the two-key release note is itself the finding worth surfacing: this package needs a documentation review before it gets near production credentials.