Sellsy Laravel Package

Technical Evaluation

Architecture fit

The package is positioned as an "Embedded OpenAPI Connector" for Sellsy, packaged within the Splash connector family. That phrasing implies a thin, likely generated client layer (OpenAPI-derived DTOs and request builders) wrapped around Sellsy's REST API, plus Splash's own connector conventions for auth, pagination, and transport. For a Laravel application already standardised on illuminate/* components and Composer, the integration surface is conventional: a service provider, configuration, and a client object injected via the container. The real architectural question is whether the package depends on the broader Splash runtime (a connector registry, credential store, or job/queue abstractions) or stands alone. If it is coupled to the Splash framework, adopting it means adopting a second framework's idioms inside Laravel, which is a meaningful tax.

Critically, the metadata available is thin: zero stars, zero dependents, score 0, hosted on GitLab rather than the package's more discoverable ecosystem. None of that is disqualifying in isolation — private or internal-distribution connectors routinely look like this — but combined it means the package has no observable production usage and no community signal. Treat it as an untested, single-owner artefact until proven otherwise.

Integration feasibility

Feasible but needs verification before commitment. The main integration work is not writing HTTP calls; it is establishing whether the connector is complete against the Sellsy endpoints the product actually needs, and whether it handles Sellsy's OAuth2 token lifecycle, rate limiting, pagination, and error envelope correctly. Sellsy's API is versioned and has moved between v1 and v2 semantics historically, so confirming which API generation the connector targets is a prerequisite, not a detail.

Technical risk

• Bus factor of one. A GitLab-hosted connector under splash-connectors is almost certainly maintained by a small team or single author. No stars and no dependents implies no external contributors and no community bug-finding.
• Generated-code fragility. Embedded OpenAPI connectors are typically regenerated from a spec snapshot. When Sellsy changes a field, a pagination scheme, or a rate-limit header, the fix lands upstream on someone else's schedule.
• Abandonment risk. There is no signal of recent activity in the supplied metadata, and Composer will not tell you it has gone quiet until a PHP or Laravel upgrade breaks it.
• Security surface. The package holds OAuth client credentials and refresh tokens. A low-visibility dependency handling auth material warrants a read of the source, not just the README.

Key questions

1. Does it depend on the full Splash runtime, or is it independently installable via Composer?
2. Which Sellsy API version and OAuth2 flow does it implement, and does it handle refresh proactively?
3. What is the endpoint coverage versus what our product actually calls? Is anything we need absent?
4. What PHP and Laravel versions are supported, and is there a CI matrix proving it?
5. Who maintains it, what is the release cadence, and is there a committed support arrangement?
6. Is the source readable and forkable — could we own it if upstream stalls?

Integration Approach

Stack fit

Good on paper. A Laravel application already using Composer, service providers, and config publishing gains a vendor-neutral HTTP client with typed payloads — the kind of dependency that reduces boilerplate for a complex CRM API. The fit degrades sharply if the connector drags in Splash's own application kernel, credential abstractions, or queue conventions; that would put two competing frameworks in one codebase.

Migration path

Do not rip out an existing Sellsy integration for this. Sequence it as an additive adapter behind an internal interface: define a SellsyClient contract in application code, implement it with this package for a subset of endpoints, and keep the existing path live. If the package proves out, expand coverage behind the same interface; if it does not, the contract remains and the swap is a single binding change. The internal interface is the insurance policy, and it costs little to build first.

Compatibility

Pin explicitly — package version, PHP version, Laravel version — and commit a composer.lock. Verify against the lowest PHP version in the supported matrix, not just the developer's machine. Check for conflicts with existing Guzzle/PSR-7 versions, since generated OpenAPI clients frequently pin older HTTP client majors.

Sequencing

1. Source review of the repository: dependency tree, tests, CI config, recent commits, issue tracker.
2. Spike against a Sellsy sandbox: authentication, one read and one write, pagination, and a deliberate rate-limit and 401 to observe failure behaviour.
3. Wrap behind the internal contract; integrate for one non-critical endpoint.
4. Soak in staging through a token-refresh cycle and a Sellsy-side incident.
5. Expand coverage; negotiate upstream support or fork under our own namespace before it becomes load-bearing.

Operational Impact

Maintenance

This is the dominant cost. An unstarred, zero-dependent connector shifts the maintenance burden to us by default. Budget for periodically diffing the package against the live Sellsy API and being prepared to patch locally. A vendor fork under an internal namespace — with upstream syncs as deliberate merges rather than automatic updates — is the realistic steady state for anything revenue-adjacent.

Support

Effectively none beyond the maintainer's goodwill. There is no community to triage issues, no Stack Overflow corpus, and no third-party tutorials. Internal documentation and a named owner are mandatory before this touches production. Contractual support from the vendor, if purchasable, is worth pricing.

Scaling

Sellsy enforces API rate limits, and CRM sync workloads are bursty — batch imports, backfills, and reconciliation jobs will collide with interactive user traffic. Confirm the connector surfaces rate-limit headers and backoff, and wrap calls in our own queue with jitter and concurrency caps rather than relying on the package to throttle. Also watch memory on large paginated reads: generated clients often hydrate full object graphs per page.

Failure modes

• Silent auth expiry when refresh tokens rotate or are revoked out-of-band.
• Schema drift: Sellsy adds or renames a field, deserialisation fails or silently nulls.
• HTTP client version conflict surfacing at deploy rather than at install.
• Unhandled 429s cascading into sync backlog.
• Maintainer abandonment discovered only at the next PHP major upgrade.

Instrument all outbound calls with structured logging, alert on auth failures and elevated 4xx/5xx rates, and add a contract test that hits a recorded fixture set on every deploy.

Ramp-up

Low for a developer familiar with Laravel and the Sellsy domain; the cognitive cost is not the package's API but the Splash conventions layered underneath it and the absence of documentation. Estimate one to two days of source reading and sandbox experimentation before productive work, plus more if the Splash runtime is a hard dependency. The larger ramp-up risk is organisational: the knowledge will sit with whoever does that reading, so pair on it and write the runbook while the context is fresh.