Ardaccess Bridge Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy/integrate for physical access control: This package is a thin Symfony bridge to the ARD Access REST API (carriers/people, events, smart objects). It lets you avoid building a raw HTTP client and auth/config plumbing for ARD Access, so the real decision is whether ARD Access is the right access-control system, not whether to write a wrapper.
• Feature scoping for access-control-adjacent products: Directly supports features around badge/carrier lifecycle (create/update carriers), event and supervision queries (search events by criteria), and smart-object handback (e.g., returning a key/fob at a reader). Useful for roadmap items like "contractor badge issuance," "site access audit log," "visitor check-in/out," and "key return workflows."
• Roadmap sequencing and integration risk: Because this is a Symfony bundle (not a Laravel package), it informs sequencing: if your product is Laravel-based, budget for a framework adapter/anti-corruption layer before committing roadmap dates. If your platform is Symfony, integration effort is low.
• Buy vs. build for the integration layer: The package is small and pre-1.0-maturity (v1.0.2, single maintainer, config-file-driven). PM decision: adopt for prototypes and internal tools; for customer-facing production, plan to wrap it behind your own interface so you can swap vendors or replace it.
• Vendor lock-in and exit strategy: Since the client exposes ARD-specific concepts (carrier, creator criteria builder, smartobject), treat it as a vendor-coupled dependency. This supports a decision to define an internal access-control domain model and keep ARD-specific code at the edges.
• Use cases it unblocks quickly: admin back-office tools for managing cardholders, access-event search/reporting dashboards, and reception/desk workflows (handback of smart objects). These are good candidates for a time-boxed spike to validate vendor fit.

When to Consider This Package

Consider it when:

• You are on Symfony (the package is a Symfony bundle, despite being filed here as Laravel/PHP), and you need to talk to an ARD Access system over its REST API.
• Your needs map to the exposed surface: carrier CRUD/listing, event listing with criteria-based search, and smart-object handback.
• You want a fast proof of concept: config in framework.yaml/services.yaml, inject ArdaccessService, call methods. Low ceremony.
• Your integration is internal or back-office, where a single-maintainer dependency and basic username/password auth are acceptable.
• You need only read/reporting or straightforward writes, not high-throughput or transactional guarantees.

Look elsewhere or plan significant wrapping when:

• Your stack is Laravel — this is not a Laravel package; expect to build a service provider/adapter or use the underlying ARD client directly.
• You need strong maintenance guarantees, SLA, security review, or enterprise support. v1.0.2 with one maintainer, static credentials in YAML, and http in the example config are all adoption risks.
• You require OAuth/token-based auth, mTLS, or secret management — credentials are configured in plain YAML here.
• You need coverage beyond carriers, events, and smart-object handback, or you need pagination/rate-limit/retry semantics that aren't documented.
• You are doing high-volume or latency-sensitive access decisions; a synchronous REST bridge is likely the wrong architecture — consider direct SDK/vendor integration or event streaming.

How to Pitch It (Stakeholders)

For executives: We found a small open-source Symfony connector to ARD Access, the physical access-control system. It's a low-cost way to prove out integrations — cardholder management, access-event reporting, and key/smart-object return workflows — without building an API client from scratch. It is not a strategic dependency: it's a single-maintainer, pre-1.0-style package with credentials configured in plain files, and it's built for Symfony, not our Laravel stack. Recommendation: fund a short, time-boxed spike to validate ARD Access as a vendor and to size the adapter work; do not put it on a customer-facing critical path until we've wrapped it behind our own interface.

For engineering: Treat this as a convenience wrapper, not an abstraction. Two concrete asks: (1) put it behind an internal AccessControlClient interface so ARD specifics (carrier, creator criteria builder, smartobject) don't leak into domain code; (2) budget for a Laravel adapter (service provider + config) since this ships as a Symfony bundle with framework.yaml/services.yaml wiring. Also flag the security posture — example config uses http and inline username/password — so we need secret management and TLS enforcement before any non-local use. Pin the version, since it's a 1.0.x with a single maintainer and API surface we don't control.

For the delivery team: Scope the spike to three flows: list/update carriers, search events by criteria, and handback a smart object. If those cover the near-term roadmap, the integration pays for itself quickly; if we need broader ARD coverage or stricter auth, we should evaluate the vendor's own SDK before committing.