User Api V1 Laravel Package

Technical Evaluation

Architecture fit. This is a single-class, framework-agnostic PHP wrapper around Zadarma's REST API — not a Laravel package. There is no service provider, no config file, no facade, no DI contract, and no Composer/Laravel version constraints. It is a thin transport layer: constructor takes key/secret, one call()-style method builds a signed request and returns decoded JSON/XML. Functionally that is fine inside Laravel, but it delivers zero framework integration — you supply all of the glue (config, container binding, facade, error mapping).

Integration feasibility. Low-to-moderate. The code surface is small enough to read end-to-end in an hour and wrap in an adapter. The friction is packaging: with 63 stars and 0 dependents, this is almost certainly not on Packagist, so consumption requires a VCS repositories entry pinned to a commit/tag, or vendoring the file. Either is acceptable for a single internal service; neither is acceptable as a loosely-pinned dependency across many services.

Technical risk.

• Staleness / bus factor. Last release 2023-01-17; the underlying code is older than that. Effectively one informal maintainer tied to the vendor (Zadarma is the VoIP/PBX vendor itself). Risk of abandonment is real but bounded — if the vendor abandons its own SDK, the API is probably changing too.
• API version lock. The package targets API v1. If Zadarma ships v2 or changes the HMAC/signature scheme, the wrapper breaks with no upgrade path from the package.
• Error handling. Hand-rolled cURL with no retry/backoff, no PSR-3 logging, no typed exceptions, no response objects. Failures surface as raw decode results or silent falsy returns — dangerous in telephony flows (missed calls, SMS, PBX events are business-critical, not cosmetic).
• Security surface. Credentials are passed as constructor strings and are likely captured in debug output; TLS/CA verification and timeout settings need to be confirmed by inspection, not assumed.

Key questions. Is it on Packagist or must we pin a SHA? Which PHP versions does it actually support (8.2/8.3 cleanly)? Does it handle non-2xx and rate-limit responses distinctly? Does the signature helper use hash_hmac/hash() or deprecated primitives? Is v1 of the API still the vendor's supported version, and what is its deprecation policy? Is there a callback/webhook story, or is that entirely on us?

Integration Approach

Stack fit. Poor as a package, fine as a library. It requires the cURL extension and nothing else, which means it will not fight Laravel's dependency graph — but it also will not benefit from it. The realistic pattern is an anti-corruption layer: App\Services\Telephony\ZadarmaClient interface, a LegacyZadarmaAdapter implementing it around this class, and a config file holding credentials from env/secret manager.

Migration path. Treat the vendor class as a vendored, pinned artifact behind the adapter — not as a dependency we plan to upgrade. If Zadarma publishes v2 or a maintained SDK, only the adapter changes. If we decide the wrapper is too thin to justify the dependency, the fallback is a ~150-line client on Laravel's HTTP client implementing the same signature scheme; keep the adapter boundary so that decision stays cheap either way.

Compatibility. No Laravel constraints means no version conflicts, but also no compatibility guarantees — verify on PHP 8.2+ and Laravel 10/11/12 explicitly with a smoke test against the live/sandbox API before adoption. Watch for notices from untyped properties and dynamic property creation under PHP 8.2+.

Sequencing. (1) Pin a commit and vendor it. (2) Config + secret injection. (3) Adapter interface and container binding. (4) Contract tests against a Zadarma sandbox account covering success, auth failure, and timeout. (5) Move all outbound calls behind queued jobs with retry/backoff. (6) Build the inbound webhook endpoint in-app (signature verification is our responsibility). (7) Only then wire business features.

Operational Impact

Maintenance. Near-zero upstream churn is a double-edged sword: no upgrade treadmill, but no security patches either. Budget a quarterly review of the pinned commit versus upstream and the vendor's API changelog. Owning the fork is a realistic outcome.

Support. No commercial support for the package; vendor support covers the API, not the PHP class. On-call engineers debugging a failed call-flow will be reading unannotated legacy-style PHP — mitigate with internal docs on the signature algorithm and a request/response logging wrapper.

Scaling. Synchronous cURL in the request path is the main hazard. Every API call must be queued with concurrency limits and retry/backoff, since rate limits are vendor-side and undocumented in-code. Expect to add circuit breaking so a Zadarma slowdown does not exhaust PHP-FPM workers.

Failure modes. Signature mismatches after credential rotation; silent empty responses masking 4xx; timeouts mid-call-flow; TLS verification failures after CA bundle changes; vendor deprecating v1. None of these are surfaced clearly by the package, so instrumentation must be added at the adapter.

Ramp-up. Low individually — a mid-level PHP developer can absorb the class in under a day. The real ramp-up cost is domain knowledge: Zadarma's parameter sorting, signature construction, and endpoint semantics. Capture that in the adapter and its tests, not in tribal memory.