Keen Delivery Laravel Package

Technical Evaluation

Architecture fit. This package sits in the label-generation layer of a Laravel application: it wraps sendynl/php-sdk and exposes label creation (single and bulk) to domain code, presumably via a facade/service class and a config file. That is a thin-adapter architecture, which is appropriate — it keeps vendor SDK types out of controllers and jobs, and gives one seam to patch when the vendor drifts. The v3.1.1 change reinforces that the adapter is doing its job: it now supplies an explicit paper type (A6) and print position (top-left) instead of relying on the SDK's implicit default.

Integration feasibility. Low effort. The change is a patch release; consuming it means a composer constraint bump (^3.1.1) and a deploy. No schema, queue, or API contract changes are implied. The only integration surface that moves is the printed artefact itself, which is exactly the surface that is hardest to verify automatically and easiest to overlook until a warehouse rejects a batch.

Technical risk. Moderate, concentrated in one place. The release note documents a silent semantic change: sendynl/php-sdk v3 "no longer defaults the paper type." Two distinct risks follow:

1. Direct-SDK call sites. Any code in our codebase that calls sendynl/php-sdk directly — bypassing the wrapper — will now send no paper type and inherit whatever the vendor API does with an absent value. That is undefined behaviour from our side. It may print on A4, may error, or may be accepted and mis-printed. This is the highest-severity item in the release.
2. Wrapper coverage. v3.1.1 pins A6/top-left for bulk labels specifically. The note does not say whether single-label paths, or bulk paths with caller-supplied overrides, get the same treatment. If a caller passes their own paper type through, the fix should not clobber it; if a caller passes nothing on a non-bulk path, the question is open.

The mitigating factor is that pinning a previously-implicit default to an explicit value is behaviour-preserving by design — it converts a dependency on vendor defaults into a dependency on our own config. That is strictly better hygiene, and it is the correct response to an upstream default removal. But it is only correct for the paths it actually covers.

Key questions.

• Did this release also adopt sendynl/php-sdk v3 as a major-version bump, or was v3 already in place? If v2→v3 landed here, the paper-type fix is likely one of several breaking changes and the release notes are under-reporting.
• Does the wrapper expose paper type and offset as configurable, or are A6/top-left now hard-coded? Hard-coding is acceptable as a default but should be overridable for customers on A4 or 4×6 thermal.
• Are there direct sendynl/php-sdk call sites in our application that bypass the wrapper?
• Is the pinned position (top-left) a default applied when unset, or an override applied unconditionally?
• Is there any test asserting the outgoing request payload contains the paper type? Without one, this regresses silently.

Integration Approach

Stack fit. Standard Composer package for Laravel; config-published, service-provider-registered. No new infrastructure, no new runtime dependency beyond the SDK constraint. Fits within an existing deployment pipeline without new operational surface.

Migration path. Treat this as a two-step, not a one-step, upgrade:

1. Discovery first. Grep the codebase for direct sendynl/php-sdk usage outside the wrapper before bumping anything. If found, those sites need explicit paper type arguments or need to be routed through the wrapper. This is a prerequisite, not a follow-up.
2. Then bump. Update the constraint, run composer update sendynl/php-sdk, and — critically — render a real bulk label to PDF and inspect paper size and print origin. A unit test asserting the request payload carries A6/top-left should land in the same PR.

Compatibility. PHP and Laravel version constraints are unstated in the release note; verify against our runtime matrix. The behavioural contract for callers of the wrapper is unchanged for bulk labels (same on-paper result, now explicit). The contract does change for anything reaching the SDK directly, and for any configuration that previously relied on the vendor's default rather than our config file.

Sequencing. Ship behind a short-lived feature flag or in a canary environment where a physical or PDF render can be eyeballed before it reaches warehouse operators. Because the failure mode is mis-printed labels rather than exceptions, a green test suite is not sufficient evidence of correctness. Sequence: discovery → payload test → canary render → production.

Operational Impact

Maintenance. Net positive. Explicit paper type removes a class of "vendor changed a default and our labels moved" incidents, and makes the printing contract visible in our config rather than hidden in a dependency. The cost is that we now own the default and must revisit it when the vendor adds paper sizes or changes position semantics — a small, predictable maintenance obligation.

Support. Expect a short tail of tickets if any team was producing bulk labels through a direct SDK path and now sees A4 output or API rejections. Support scripts should ask "which code path generated this label" before debugging layout. Document the A6/top-left default and how to override it, so first-line support does not escalate layout questions to engineering.

Scaling. Neutral. Paper type is a request parameter; it does not affect throughput, batching, or vendor rate limits. The change is orthogonal to whatever bulk-concurrency story exists.

Failure modes to watch.

• Silent mis-print: labels render on the wrong stock and pass all automated checks. Detect via a payload assertion plus periodic physical/PDF sampling.
• Partial coverage: bulk fixed, single-label path still defaulting to nothing. Detect via a matrix test across all label-producing entry points.
• Override clobbering: a caller's explicit A4 request silently forced to A6. Detect via a test that passes a non-default paper type and asserts it survives.
• Direct-SDK drift: bypassed call sites break weeks later when a separate deploy touches them. Detect via static analysis / architecture test forbidding sendynl\ imports outside the wrapper namespace.

Ramp-up. Minimal for engineers already using the wrapper — it is a patch bump. The real ramp-up cost is organisational: getting the team to accept that "labels look right" is not the same as "labels are correct," and that print output needs a manual verification step in the release checklist. Given the terse release note, the first hour of engineering time is best spent reading the SDK v3 changelog rather than reading this note, which almost certainly understates the scope of the v3 transition.