Yousign Api Client Laravel Package

Product Decisions This Supports

• Feature scoping for e-signature: whether to ship in-product contract/consent signing (sales quotes, SEPA mandates, HR onboarding, supplier agreements, ToS acceptance) or defer it. The SDK turns "integrate e-signature" from an unbounded research item into a sized backlog item.
• Build vs. buy, decided correctly: e-signature is a compliance product, not a CRUD feature. Qualified signatures, audit trails, timestamping and identity verification are not things a product team should build. This package is the buy-side integration cost — it makes the "buy" option cheap enough that "build" should be removed from the table early.
• Vendor selection within the buy decision: Yousign is a French, eIDAS-oriented provider. Choosing it is a market/compliance decision (EU data residency, qualified signatures, French legal familiarity), and this client is the PHP-shaped consequence of that choice, not the reason for it. Keep the two decisions separate on the roadmap.
• Roadmap sequencing and market entry: if the product targets France/EU, e-signature is table stakes for B2B sales motion. If the product is US-first, this vendor and client are likely the wrong default — a US-centric provider will have better fit and fewer cross-border friction points.
• Architecture decisions: this is a server-side PHP client, so it implies a backend-mediated signing flow — your app creates signature requests, redirects users to hosted signing pages (or embeds), and reconciles state via webhooks. That shapes the decision on asynchronous job processing, webhook ingestion, idempotency and document storage/retention.
• Pricing and packaging inputs: envelope volumes, per-signature costs and seat tiers become forecastable once you know the integration shape; the SDK itself gives you the object model (procedures, signers, documents) to model usage.
• Compliance and data-handling review: DPAs, retention policy, audit-evidence export and where signed documents live — decisions that belong on the roadmap before, not after, the first signed contract.

When to Consider This Package

Consider it when:

• The stack is PHP/Laravel and Yousign is already the chosen or shortlisted provider. Using the vendor's own client is preferable to hand-rolling HTTP calls against a versioned API.
• You need EU/French legal weight — eIDAS simple/advanced/qualified signatures, GDPR-aligned processing, EU-hosted evidence.
• You want first-party maintenance: the client is published by Yousign itself, so it tracks their API rather than a third party's interpretation of it. Note the caveat: the repository shows no stars and zero dependents, which is a weak adoption signal. Treat that as "unproven in the wild," not "abandoned" — vendor SDKs are often consumed privately — but verify commit recency, supported API version, and release tags before betting a roadmap milestone on it.
• The integration is a bounded, well-understood flow: create a signature request, attach a PDF, add signers, send, listen for completion. This client is a thin wrapper and is well suited to exactly that.

Look elsewhere when:

• The stack is not PHP — use the corresponding official client or the REST API directly; don't introduce a PHP service just to use this.
• You need rich embedded signing UX with deep branding and in-app control; evaluate Yousign's embedded options and competing providers on UX capability rather than on client ergonomics.
• Your market is US/global-first and DocuSign or Dropbox Sign fit better commercially; the client's quality is irrelevant if the vendor is wrong.
• You need document generation, CLM, or notarization in the same purchase — confirm scope before assuming this covers it.
• Lock-in risk is unacceptable: the client is a thin wrapper, so the sane mitigation is to depend on your own SignatureProvider interface and keep the vendor SDK behind it. If you cannot afford even that abstraction layer, the constraint is your architecture, not the package.

How to Pitch It (Stakeholders)

To executives: E-signature is a compliance capability, not a differentiator — we should buy it, not build it. Yousign is a French provider built around EU signature law (eIDAS), which matters if we sell into France and the EU. This PHP client is the vendor's own integration library, so the cost of wiring it in is measured in days, not quarters. The decision to make is vendor and market fit; the client is the cheap part.

To engineering: It's a first-party Composer package wrapping Yousign's REST API — install it, keep it behind a thin adapter interface, and treat the vendor object model as an implementation detail. The repository has minimal public traction, so budget for contract tests against a sandbox, verify it supports the API version we need, and confirm webhook signature verification is handled. Assume we will need idempotent webhook processing and a document-retention story regardless of client.

Ask: a one-to-two sprint spike on a single real document flow (create → sign → webhook → store evidence) to confirm the client's coverage and our abstraction holds. That spike produces the estimate; everything else here is a paper decision until then.