Vendra Api Laravel Package

Technical Evaluation

The package's identity is unresolved, and that is the first decision. Two sources in this bundle describe mutually exclusive products. description.md claims an outbound HTTP client ("clean, expressive client for the Vendra API", fluent request builder, facade, Http::fake()-testable). SKILL.md describes inbound API Platform infrastructure: shared ApiResource DTOs such as ResourceReference, service-provider wiring, a namespace of Misaf\VendraApi, and an arch test forbidding any dependency on Misaf\VendraTenant. Those cannot both be true of the same subtree split. The skill file is far more credible — it names concrete classes, constraints, and a test command — which suggests description.md is stale or auto-generated marketing copy. Do not plan against the description until someone has run ls src/ and cat composer.json and confirmed which one ships. Every downstream estimate is fiction until then.

Architecture fit: this is a fan-in hub, not a leaf dependency. The skill file lists six first-party consumers (vendra-faq-api, vendra-product-api, vendra-multimedia-api, vendra-blog-api, vendra-custom-page-api, vendra-cart-api) and states that public signatures are "consumed by every domain API module." That reframes adoption entirely: you are not adding a convenience library, you are adopting the shared spine of a modular API platform. The blast radius of any change — including a minor bump — is the whole domain-module surface, not one integration.

Integration feasibility: bifurcated, with no middle option. If we are building on the Vendra platform, feasibility is high: Composer install, auto-discovered provider, stable namespace, Pest suite, Pint and composer stan already wired. If we are an outside team that wants a client for the Vendra REST API, feasibility is poor and probably blocked — a [READ ONLY] subtree split means the repo will not accept our fixes, issues, or PRs, and upstreaming requires access to misaf/vendra itself.

Technical risk, ranked:

• Version-graph skew. The skill mandates self.version alignment "across the Vendra package graph." Misaligned versions across six sibling modules is the most probable production failure and the hardest to diagnose.
• Hard coupling to API Platform. The transitive policy explicitly declares an exposed Vendra dependency part of the public contract: "Removing or replacing an exposed dependency is a breaking change." Replacing API Platform later is not a refactor, it is a platform migration.
• Uncharacterised upgrade surface. v1.10.0 jumps to v1.12.3 with a compare link as the entire release note. Two minor versions of undocumented change sit between the last described state and current.
• Boundary erosion. The architecture's integrity depends on nobody adding domain resources, routes, or a localization/tenant dependency here. The ArchTest.php security preset is the only automated gate.
• Weak external signal. One star and a read-only mirror mean no community triage, no issue archaeology, no Stack Overflow corpus. Star count is not a quality proxy for a build artifact, but it does mean zero external safety net.

Key questions to answer before committing:

1. HTTP client or API Platform DTO library — which is actually in src/?
2. Who owns upstream misaf/vendra, and do we have commit access, or only vendored consumption?
3. Is this a licence to build on Vendra, or an attempt to integrate with it from outside? A no on the former likely ends the evaluation.
4. What in the v1.10.0…v1.12.3 diff touches public signatures?
5. Which domain API modules do we actually need, and can they be adopted incrementally or only as a set?

Integration Approach

Stack fit. Laravel with API Platform, Composer, Pest. The presence of skills/vendra-api-development/SKILL.md with a prescribed workflow (vendor/bin/pint --dirty --format agent, php artisan test --compact --testsuite=vendra-api, composer stan) is a genuine asset — the repo ships agent-ready contribution instructions, which materially lowers onboarding cost and is rarer than the star count implies. Treat the skill file as the authoritative integration guide and demote assessment-laravel_dev.md to background reading.

Do not apply the generic Laravel onboarding guide literally. The bundled assessment is a sensible generic template and a poor fit here. Publishing config (vendor:publish --tag=vendra-config), wrapping the client behind App\Services\Vendra\VendraClient, retrying on 429/503, and Http::fake() fixtures all assume an outbound HTTP SDK. If this package is DTOs and provider wiring, most of that advice is inapplicable or actively misleading. A TPM should flag this document as a source of wasted engineering effort if circulated unedited.

Migration path: whole-graph adoption, not cherry-picking. Because the repo is a read-only split with self.version alignment, the viable path is to require the Vendra package set at a single consistent version and take updates as a unit. Local patches must go into misaf/vendra upstream, never into vendor/ — a patched vendor tree is the failure mode this architecture is most vulnerable to.

Compatibility gates, in order:

1. Confirm the API Platform major version this package pins; that constrains the host application's Laravel and API Platform versions and is the true compatibility ceiling.
2. Pin ^1.12 in composer.json and commit the lockfile. No floating constraints across a six-module graph.
3. Verify auto-discovery via extra.laravel in composer.json; only fall back to manual registration in bootstrap/providers.php (Laravel 11+) if absent.
4. Run tests/ArchTest.php in the host app — the not->toUse('Misaf\VendraTenant') assertion is the cheapest possible early-warning for boundary violations.

Sequencing. (1) Resolve the identity question with a src/ inventory — half a day. (2) Read the v1.10.0...v1.12.3 diff and classify each change as public-contract or internal. (3) Get access to the monorepo or a named upstream contact; if neither exists, stop. (4) Adopt one domain module end-to-end — vendra-product-api is the likely pilot, being closest to core revenue paths — and prove the graph builds, tests, and deploys before expanding. (5) Only then add further domain modules.

Operational Impact

Maintenance. We inherit the maintenance posture of misaf/vendra, not of this repo. This repo is a publishing artifact: no issues triage, no PRs, no README-level troubleshooting. The practical consequence is that we must hold enough monorepo familiarity to read upstream commits directly, and we should assume a single-maintainer risk profile until proven otherwise. Budget explicit capacity for tracking upstream — this is not a package you install and forget.

Support. Escalation has one hop: the upstream monorepo maintainer. There is no community fallback. If the upstream goes quiet, we fork — and forking a shared-spine package across six domain modules is a multi-week commitment, not a hotfix. That scenario should be named and accepted (or mitigated with a vendor-access agreement) at the go/no-go decision, not discovered later.

Scaling. Technically low-risk: this layer is wiring and DTOs, with no runtime state, no I/O of its own, and no obvious throughput bottleneck. The scaling risk is organisational, not technical — change amplification. One signature change here is a coordinated release across every consuming module. Keep the public surface deliberately narrow; every addition is multiplied by six.

Failure modes to monitor:

• Cross-module version skew after a partial update — enforce lockstep bumping in CI.
• A local vendor patch surviving into production because upstreaming stalled — lint for modified vendor files.
• Boundary drift: a domain resource, route, or locale/tenant dependency added by an engineer taking the shortest path — the arch test is the gate, and it must run in CI, not just locally.
• Silent upgrade damage from the undocumented v1.10→v1.12 delta — treat the first upgrade as a regression-testing exercise with real payload assertions on ResourceReference and shared DTO serialisation.
• Stale description.md misleading a new joiner into wiring an HTTP client that does not exist.

Ramp-up. A competent Laravel developer is productive inside one domain module in roughly two to three days. Being safe in packages/vendra-api is a different bar: it requires API Platform's resource/state-provider model, Composer package-graph discipline (self.version alignment, transitive dependency policy), and the monorepo's release ritual. Plan a week to first safe contribution, and do not staff this package with whoever is free — it is the highest-leverage and least forgiving code in the tree.