- What is kolirt/laravel-ukrposhta and what does it do?
- It is a thin Laravel service-provider wrapper around the Ukrposhta HTTP API, the Ukrainian national postal operator. It registers a configured client in Laravel's service container and exposes per-domain resource classes for tracking shipments, address and dictionary lookups, and waybill or shipment operations. The main value is removing hand-rolled Guzzle boilerplate: credentials come from published config, and the client is injected rather than built by hand. It is not a full logistics or order-management abstraction, so treat it as a transport layer and keep your own domain interfaces on top.
- How do I install kolirt/laravel-ukrposhta in a Laravel application?
- Install it with Composer using composer require kolirt/laravel-ukrposhta, then publish the package config and add your Ukrposhta API token to your environment file or secret manager. The package does not imply any database migrations or front-end assets, so installation is essentially Composer plus configuration. Because the current line is 1.0.x, pin an explicit constraint such as ^1.0.3 and review minor updates before bumping.
- How do I configure the Ukrposhta API token and base URI?
- After publishing the config file, set the Ukrposhta API token and base URI through environment variables referenced by that config, keeping real credentials out of version control. The client is bound as a singleton in the container, so any config changes require a config cache clear in cached environments. If you run multiple environments, use separate apps or tokens per environment so sandbox and production traffic never mix.
- Which Laravel and PHP versions does this package support?
- Support is declared in the package's composer.json, so check the illuminate/* and php constraints of the exact tag you intend to install rather than relying on the README. The evaluation notes a native fit for Laravel 9, 10, and 11 on PHP 8.1+, but you should confirm the constraints for 1.0.3 yourself. Also run composer why-not before merging if your app pins specific Guzzle or HTTP client versions, since transitive constraints can conflict.
- Does kolirt/laravel-ukrposhta support the Ukrposhta sandbox or test environment?
- The package exposes a configurable base URI, which is the usual mechanism for pointing the client at a sandbox or test host when Ukrposhta provides one. The context does not confirm documented sandbox support, so verify the current config keys and Ukrposhta's own test-account offering before planning integration tests. Budget time to obtain sandbox credentials and to write your own tests, because release documentation for patch versions is minimal.
- What Ukrposhta operations are covered: tracking, addresses, and waybills?
- The package is described as covering shipment tracking, address and dictionary lookups, and waybill or shipment creation through per-domain resource classes. That coverage is the advertised surface, but confirm the exact methods for your use case in the source or README before committing to it. Waybill creation additionally depends on Ukrposhta-side prerequisites such as a business account and pre-registered sender contracts, which the package cannot bypass.
- Is kolirt/laravel-ukrposhta safe to use in production?
- It is a single-maintainer package with a thin surface, so bus-factor risk is real for anything customer-facing, and package health is tightly coupled to Ukrposhta's API stability, rate limits, and token lifecycle. Version 1.0.x semver also means minor releases may change behavior, so pin ^1.0.3 and review 1.x updates deliberately. Practically, wrap the package behind your own shipping interface and add retry, timeout, and logging decorators so an upstream or maintainer change cannot ripple through your domain code.
- What changed in version 1.0.3 compared with 1.0.2?
- The 1.0.2 to 1.0.3 delta appears to be a routine patch release with no advertised breaking changes, and no narrative release notes beyond the changelog compare link. That means you cannot confirm from documentation alone whether it was a bugfix, a dependency bump, or an undocumented behavior change. Read the diff for the tag and check the composer.json constraints before upgrading, then treat it as a low-risk but unverified drop-in.
- How should I test an integration built on this package?
- Because release documentation is thin and patch releases have changelog-only notes, plan your own integration tests against real or sandbox Ukrposhta credentials rather than trusting the package's own suite. Prototype a tracking lookup and one waybill in a scratch branch to capture the error and latency profile, then add tests around your wrapper interface. Confirm whether the 1.0.3 tag has passing CI coverage before relying on it in a customer-facing path.
- What are the alternatives if this package does not fit my stack?
- If you are on Lumen or a non-Laravel PHP service, you can bypass the service provider and use the underlying HTTP client directly, though that path is unsupported. For Laravel apps, the realistic alternative is a hand-rolled Guzzle client or a legacy wrapper, which this package mainly replaces by centralizing config and request handling. If shipping is core to your domain, keep the package behind an internal ShippingProvider interface so you can swap implementations later without rewriting call sites.