- How do I install gdinko/speedy in a Laravel application?
- Require the package with Composer using composer require gdinko/speedy, then publish its configuration file with the vendor:publish command. Add your Speedy customer portal credentials and endpoint settings to the published config, and confirm the Illuminate and PHP version constraints match your app before you start. The service provider and facade are registered through standard Laravel package discovery.
- Which Speedy API endpoints does gdinko/speedy cover?
- The package advertises shipping rate calculation, shipment and label creation, label printing, parcel tracking, and reference data lookups for cities, offices, and services, plus pickup management. Coverage of edge endpoints such as shipment cancellation, cash-on-delivery, or returns is not documented in detail, so treat it as unverified. Run a sandbox spike and build a coverage matrix against the operations your business actually needs before committing.
- What Laravel and PHP versions does gdinko/speedy support?
- Version support is defined entirely by the illuminate/* and PHP constraints in the package's composer.json. Because it is a low-adoption, single-maintainer package, those constraints may not track the newest Laravel releases. Check them against your target application before the spike, pin an exact version, and commit the lockfile so a future major Laravel upgrade cannot silently strand the dependency.
- Is gdinko/speedy safe to use in production?
- It works as an outbound integration adapter, but with roughly 21 stars and a single maintainer you should treat abandonment as the base case rather than the tail case. The safer pattern is to hide it behind an application-owned ShippingGateway interface, keep a direct HTTP client implementation as a swap target, and add your own retries, timeouts, logging, and idempotency around it. That converts a vendor problem into a one-class change.
- How do I test gdinko/speedy without creating real Speedy shipments?
- Point the published config at the Speedy sandbox or test endpoint and use test credentials from the customer portal. There is no visible test suite or sandbox fixture set in the package, so also mock the facade or the underlying HTTP client in your own automated tests. Keep live sandbox calls inside a timeboxed spike and assert response shapes rather than trusting the wrapper's types.
- Does gdinko/speedy return typed DTOs or raw arrays?
- This is not documented in detail and cannot be verified from the outside, so plan for raw arrays or loosely typed responses until you read the source. Either way, map the vendor payloads into your own domain objects at the gateway boundary. Do not let the package's response types leak into controllers, jobs, or your order and shipment models.
- Can I call the Speedy facade directly from a controller or queue job?
- You can, but you should not. Calling the facade directly couples your domain to a low-adoption third-party package and makes swapping or forking it painful later. Introduce a ShippingGateway interface, implement it with this package behind a feature flag, and resolve it from the container so queued jobs, retries, and metrics stay under your control.
- Does gdinko/speedy cache the city and office reference data?
- The package exposes reference-data lookups for cities, offices, and services, but there is no documented caching layer, and Speedy's datasets are large and change regularly. Without caching you risk per-request latency and rate limiting on every checkout or label flow. Wrap those lookups in your own repository backed by Laravel's cache driver and refresh on a schedule.
- How does gdinko/speedy handle Speedy API authentication and tokens?
- Authentication is configured through the published config file using credentials from the Speedy customer portal, but token acquisition, refresh, and cross-request caching behavior is not documented. Inspect the source to confirm whether tokens are stored in Laravel's cache or re-fetched on every request, since that affects rate limits and latency. If it re-authenticates constantly, add a caching decorator at your gateway layer.
- What are the alternatives to gdinko/speedy for Laravel?
- The realistic alternatives are a hand-rolled Laravel HTTP client wrapper around the Speedy REST API, a fork of this package, or another community wrapper if one exists. Because the package is thin, a direct client is a viable fallback whenever your endpoint coverage exceeds what it offers. Keep the application-owned gateway interface regardless, so you can migrate without touching business logic.