Product Decisions This Supports
- Build vs. buy on French-market CRM/ERP integration: Sellsy is a significant CRM, billing and quote-to-cash platform for French SMBs. This connector lets you decide to partner/integrate rather than build a bespoke client from scratch, and to do so with a fraction of the discovery and schema work.
- Roadmap for embedded integrations: The “Embedded” packaging suggests an embedded-connect pattern (auth handshake, tenant-scoped access, hosted experience). That directly informs whether you can offer Sellsy sync as a first-class in-product feature versus a one-off services engagement.
- Use-case validation: Concrete workflows this unlocks — customer/company sync, quote and invoice creation, subscription and billing data mirroring, and CRM enrichment for sales or finance personas. Each is a candidate feature line on the roadmap.
- Integration surface prioritization: Because it sits in a family of Splash connectors, adopting it is a statement that Sellsy belongs in your supported-integration tier. That affects which segments you can sell to (French/EU SMB) and which you defer.
- Risk and effort estimation: The connector’s scope is narrow and generic (OpenAPI-derived). That helps scope a spike: estimate the delta between “generated client” and “production integration” (webhooks, retries, rate limits, error taxonomy) rather than estimating from zero.
- Multi-tenant product architecture: An embedded connector implies your product handles per-tenant credentials and isolation. This package feeds directly into decisions about credential storage, connector abstraction layer, and whether integrations are a platform capability or a per-feature effort.
When to Consider This Package
Consider it when:
- You are building in PHP/Laravel and need Sellsy connectivity for a French or EU SMB customer base, and you would rather start from an OpenAPI-generated client than hand-roll HTTP calls.
- You already align with, or are evaluating, the Splash connector ecosystem — a shared connector pattern is worth more than a marginally better bespoke client.
- Your need is breadth-oriented coverage (standard CRUD across Sellsy entities) rather than deep, event-driven behavior.
- You want to prototype fast to validate demand for Sellsy support before committing engineering headcount.
- You are comfortable treating the package as a starting point you own and fork, not a dependency you consume passively.
Look elsewhere when:
- You are not on PHP/Laravel — the value proposition collapses; use Sellsy’s own APIs or another language’s client.
- Maturity and support matter more than speed. Zero stars, zero dependents, and a score of 0 are adoption signals, not quality signals. There is no evidence of production users, no community, and no demonstrated maintenance cadence. For a revenue-critical billing sync, that is a real operational liability.
- You need guarantees: SLAs, security review artifacts, deprecation policy, long-term maintenance commitments. A small repository inside a connector org generally does not provide these.
- Your integration is shallow — a handful of endpoints behind a webhook. A generated client plus ~200 lines of your own code may be simpler than adopting and auditing a dependency.
- You require complete webhook/event coverage, high-volume throughput, or strict compliance handling (e.g., invoicing regulatory requirements in France). Validate coverage against Sellsy’s API surface before assuming the connector is complete.
Practical screen before adoption: verify the generated client actually covers the entities and endpoints you need, confirm how auth and token refresh are handled, check the OpenAPI spec version it was generated from, and inspect commit recency and issue activity.
How to Pitch It (Stakeholders)
For executives: Sellsy is a mainstream CRM and billing platform for French SMBs — a segment we currently cannot serve well. This package is a pre-built connector that shortens the path to a working Sellsy integration from months of bespoke work to weeks of integration and hardening. It is a low-cost option on a market expansion, not a platform bet: the package is early-stage with no visible adoption, so treat it as a head start rather than a foundation, and budget for us to own and maintain the code we ship on top of it.
For engineering: An OpenAPI-generated PHP client for Sellsy, packaged as a Splash connector, intended for embedded use. It gives us typed request/response models across core Sellsy entities and inherits the auth and connector conventions of the Splash family, which means consistency with any other connectors we adopt. The trade-off is maturity: no dependents, no community, unproven maintenance. Recommendation is to vendor or fork it, pin the OpenAPI spec version, and wrap it behind our own connector interface so we can swap the client without touching feature code. Plan explicitly for the parts a generated client never covers — webhook ingestion, retry and backoff, rate-limit handling, and error normalization — and budget a focused security review of credential and token handling before any customer data flows through it.