- How do I install splash/sellsy in a Laravel application?
- Install it with Composer using composer require splash/sellsy. The package is published from the splash-connectors GitLab group rather than Packagist's most visible listings, so if the default lookup fails add the repository to your composer.json repositories block first. Once installed, expect a service provider and a publishable config file for credentials, though you should confirm both by reading the source since the README excerpt is minimal.
- Does splash/sellsy require the full Splash runtime, or can I use it standalone?
- That is the first thing to verify, because the package is described as a Splash Embedded OpenAPI Connector rather than a plain SDK. Inspect the require block in its composer.json: if it pulls in Splash kernel, credential-store, or queue abstractions, you would be adopting a second framework's idioms inside Laravel. If the dependencies are limited to HTTP and PSR contracts, it will drop into a Laravel container cleanly. Do not assume standalone installability from the name alone.
- Which Sellsy API version and OAuth2 flow does splash/sellsy implement?
- The available metadata does not state whether the connector targets Sellsy v1 or v2 semantics, so confirm it before you commit any integration work. Sellsy has shifted between API generations historically and endpoint shapes differ meaningfully between them. Also check whether the client refreshes OAuth2 tokens proactively or only reacts to a 401, since the latter adds latency and failure modes in background jobs. These details should be visible in the auth and transport classes.
- What Sellsy resources and endpoints does splash/sellsy cover?
- The package blurb calls out companies, contacts, and invoices, which suggests CRM and accounting resource coverage. Embedded OpenAPI connectors are typically generated from a spec snapshot, so coverage mirrors that snapshot at generation time and may lag newer Sellsy endpoints. Compare the generated request classes against the specific calls your product actually makes before adopting it. Anything missing means either a fork or hand-rolled requests alongside the package.
- Which PHP and Laravel versions does splash/sellsy support?
- There is no CI matrix or version badge visible in the supplied metadata, so read the composer.json php and illuminate/support constraints directly. Test the package against your target PHP and Laravel versions in a scratch branch rather than trusting declared constraints, especially on newer Laravel releases. If the constraints are outdated you may need a fork with widened ranges, which is usually a one-line change for a thin HTTP client.
- Is splash/sellsy safe to use in production?
- Treat it as an untested, single-owner artefact until you have proven otherwise: zero stars, zero dependents, and a GitLab-only home mean no observable production usage or community bug-finding. That does not disqualify it, since many internal connectors look exactly like this, but it does mean you own the due diligence. Read the source for how it stores OAuth client credentials and refresh tokens, and confirm it does not log them. Start it behind an internal interface so you can swap it out without touching call sites.
- How does splash/sellsy handle pagination, rate limiting, and API errors?
- Generated connectors frequently implement basic pagination but skip retry and backoff logic, so verify both by reading the transport layer. Sellsy enforces rate limits and returns structured error envelopes, and a client that surfaces raw responses without mapping them will push that work into your application code. If retries are absent, wrap the client in your own job-level backoff rather than patching the vendor package. Confirm whether rate-limit headers are read or ignored.
- How can I test code that uses splash/sellsy?
- Because the client is a thin layer over HTTP, the cleanest approach is to define your own SellsyClient contract in application code and bind the package implementation in the container. In tests, swap in a fake or use Laravel's HTTP client faking against the underlying Guzzle handler so no real network calls occur. This also keeps the package out of your test suite's hard dependencies. If the package ships its own test utilities, verify they exist in the source before relying on them.
- What are the alternatives to splash/sellsy for a Laravel Sellsy integration?
- The realistic alternatives are a hand-written client using Laravel's HTTP client with typed DTOs, another community Sellsy SDK, or this package wrapped in an adapter. Writing your own is more work upfront but gives you full control over OAuth2 refresh, pagination, and error mapping, and avoids a low-visibility dependency holding credentials. If you adopt the package, do it additively behind an internal interface rather than ripping out an existing integration. That sequencing lets you validate it against a subset of endpoints while keeping the current path live.
- Who maintains splash/sellsy, and what happens if it is abandoned?
- It is hosted under the splash-connectors GitLab group, which points to a small team or single author, and the bus factor is effectively one. There is no release-cadence or recent-activity signal in the metadata, and Composer will not warn you when the package goes quiet until a PHP or Laravel upgrade breaks it. Before adopting, confirm the licence permits forking and check that the source is readable and regenerable. If you depend on it in production, budget for owning a fork and using a VCS repository entry in composer.json to point at it.