ferjul17/sellsy-api
A Laravel/PHP client for the Sellsy API that simplifies authentication and requests to Sellsy CRM and billing services, making it easier to integrate contacts, companies, invoices, and other Sellsy resources into your application.
Architecture fit. ferjul17/sellsy-api is a vanilla PHP client library, not a Laravel package. It exposes Sellsy API calls as PHP methods but ships no service provider, config publishing, facade, or container bindings, so it will not "drop in" to a Laravel application. It fits only as an isolated outbound adapter behind an application-owned interface; it should never leak its request/response objects into domain code.
Integration feasibility. Feasible but low-confidence. The integration surface is HTTP + credentials, which is straightforward to wrap in a Laravel service class. The unresolved question is which Sellsy API generation it targets. Sellsy's legacy (v1) REST/XML-RPC endpoints and its v2 OAuth2 API differ in authentication, pagination, rate limits, and resource shapes. With the source repository reported as unknown, we cannot verify endpoint coverage, auth scheme, or whether the library predates the v2 migration. That is a gating unknown, not a detail.
Technical risk. High, driven by four factors:
Key questions. Which Sellsy API version and auth flow does this client implement (API key/secret vs. OAuth2)? Does it cover the specific resources we need (companies, contacts, quotes, invoices, opportunities), or only a subset? What are its transitive dependencies and their pinned versions? Is the published source identical to the vendor tarball? What is the fallback if Sellsy deprecates the endpoints it calls mid-contract?
Stack fit. The library assumes a plain PSR-7/HTTP-client world and expects the caller to manage credentials, retries, and serialization. In Laravel this means: bind a singleton client in a service provider, load credentials via config/services.php and .env, wrap every call in a thin repository class, and translate vendor payloads into application DTOs at the boundary. The vendor client must remain a private implementation detail behind an interface so it can be swapped for the official Sellsy SDK or a hand-rolled HTTP client without touching call sites.
Migration path. Treat the package as a stopgap, not a foundation. Recommended path: (1) implement against our own SellsyClientInterface; (2) back it with this library for the initial delivery if the API-version question resolves favorably; (3) maintain a parallel adapter backed by Sellsy's official v2 SDK; (4) cut over via a feature flag once parity is proven on read paths, then write paths. If the library is v1-only, this is not a migration path so much as a scheduled replacement — plan the v2 adapter from day one rather than after the v1 shutdown notice.
Compatibility. Verify PHP version support against our runtime (Laravel 10/11 run PHP 8.1+), and confirm the HTTP client dependency does not conflict with the Guzzle/Laravel HTTP versions already locked in composer.json. Because the package is archived, expect to fork it into a private VCS repository and pin a commit SHA; installing directly from Packagist leaves us exposed to a yanked package or an unreachable tag.
Sequencing. Do not parallelize the API-version investigation with build work. Sequence: (1) vendor due-diligence spike — confirm API generation, auth flow, and coverage against a sandbox Sellsy account; (2) security and license review of dependencies; (3) private fork with pinned SHA, if approved; (4) interface definition and adapter implementation; (5) integration tests against the sandbox, including error and rate-limit paths; (6) production rollout behind a flag with a rollback switch. Budget an explicit contingency for the spike concluding "unsuitable," in which case the plan collapses to the official SDK and the only sunk cost is the spike.
Maintenance. The maintenance burden transfers entirely to us at adoption. There is no upstream to file issues against; every bug fix, PHP-version bump, and dependency patch is an internal fork commit. Estimate ongoing ownership as a small but permanent tax — realistically a few engineer-days per quarter for dependency hygiene, plus unbounded effort if Sellsy changes an endpoint we depend on. This is the single largest total-cost-of-ownership driver and should be priced into the decision, not treated as a footnote.
Support. No vendor support, no SLA, no security disclosure channel. Internal escalation is the only path, meaning the on-call rotation must be able to read the library's source under incident pressure. Document the request/response shapes we depend on so debugging does not require reverse-engineering the client mid-incident.
Scaling. The library itself is a thin HTTP wrapper, so throughput is bounded by Sellsy's API rate limits and by our own concurrency handling, not by the package. But it likely provides no built-in retry, backoff, circuit breaking, or connection pooling — those must be layered on with Laravel's HTTP client middleware or a queue. Bulk sync operations (initial company/contact import) should run through queued jobs with idempotency keys rather than synchronous requests, otherwise rate-limit responses will surface as user-facing errors.
Failure modes. Expect and instrument for: credential expiry or rotation (particularly if OAuth2 with refresh tokens, which an archived client may not handle); rate-limit responses with no automatic backoff; silent schema drift returning unexpected payloads that break deserialization; unhandled HTTP errors leaking vendor exceptions into application logs; and total failure at Sellsy-side deprecation with no upstream patch available. Each of these needs an explicit detector — structured logging on every outbound call, alerting on error-rate thresholds, and a health check that validates credentials independently of user traffic.
Ramp-up. Low technical ramp-up (it is a thin client; a mid-level engineer can read it in an afternoon) but high organizational ramp-up, because the risk is concentrated in unknowns rather than complexity. The team must absorb the role the maintainer abandoned: dependency ownership, API-version tracking against Sellsy's roadmap, and fork governance. Plan for a named owner before adoption — an archived dependency without a designated internal maintainer is an unowned liability, and the cost of that gap surfaces at the worst possible moment.
How can I help you explore Laravel packages today?