- Is imper86/allegroapi a Laravel package?
- No. imper86/allegroapi is a framework-agnostic PHP SDK for the Allegro.pl REST API. It does not ship a Laravel service provider, config file, facade, or Eloquent models. In a Laravel application you install it as a library and wire its PSR-18 client, request factory, and token provider yourself.
- How do I install and configure imper86/allegroapi in Laravel?
- Install it with Composer, then construct the SDK client manually. You need a PSR-18 HTTP client such as Guzzle, a PSR-17 request factory, and a PSR-16 cache or token provider for OAuth storage. There is no auto-discovery, so register the configured client in a service provider or bind it through the container yourself.
- Does imper86/allegroapi support Laravel 10 and Laravel 11?
- Because the SDK is framework-agnostic, Laravel 10 or 11 compatibility depends mainly on PHP and PSR implementation versions rather than Laravel itself. Resolve Composer constraints early and check the package's PHP floor against your runtime. If a conflict appears, locking a minor version or a thin fork with a composer.json bump is usually the cheapest fix.
- How do I authenticate with the Allegro API using this SDK?
- The SDK expects OAuth2 tokens for Allegro. User-scoped calls use the authorization-code flow with PKCE, while app-scoped calls can use client credentials. The SDK provides typed request and response classes, but you must implement the authorization redirect, token exchange, and persistence around it.
- How should I store and refresh Allegro OAuth tokens in Laravel?
- Back the SDK's PSR-16 token store with Laravel's cache or database and encrypt the tokens at rest. Refresh tokens can be rotated, so protect refresh calls with an atomic lock to avoid concurrent refresh races. Add middleware that retries once on a 401 after a successful refresh, and log failures so broken credentials do not fail silently.
- What HTTP client does imper86/allegroapi use, and does Guzzle work?
- The SDK is built against PSR-18 for outgoing HTTP and PSR-17 for request factories. Guzzle satisfies both and is already a common Laravel transitive dependency, so it usually works without adding a conflicting HTTP stack. You still need to pass the client and factory into the SDK explicitly.
- Does the SDK handle Allegro rate limits and API errors?
- Do not assume it does. Verify in the exact release you pin whether rate-limit headers and Allegro error bodies are surfaced through the typed responses or left at the HTTP layer. In most integrations you will still add rate-limit-aware backoff, error mapping, and logging around the SDK. That wrapper is also where you would normalise failures for retries and dead-letter handling.
- Does imper86/allegroapi support Allegro webhooks or push notifications?
- This is an open question for the package and should be confirmed in the source for your pinned version. The SDK is primarily a typed REST client, so do not assume push notification support. If webhooks are not covered, plan scheduled polling with updated-since or cursor semantics behind your gateway interface.
- Is imper86/allegroapi maintained and safe for production?
- Treat it as a low-maturity dependency: it has a small community, a single maintainer, and limited external validation. That does not make it unusable, but you should pin a version, review release cadence, and be prepared to fork or patch it. Wrap it behind your own AllegroGateway interface so an abandoned package can be swapped without touching domain code.
- Which Allegro API version does the SDK target, REST or SOAP?
- The project describes itself as a REST API SDK, but its history includes SOAP support for migration from Allegro's deprecated legacy API. Before committing, confirm which Allegro REST API version the release you pin actually tracks. If you do not need SOAP, scope your integration to REST-only to reduce the surface area you must maintain.