- How do I install tucker-eric/laravel-docusign in a Laravel app?
- Run composer require tucker-eric/laravel-docusign, then publish the config file with php artisan vendor:publish and set your integration key, user ID, account ID and RSA private key path in your .env. Laravel package auto-discovery registers the service provider and the DocuSign facade, so no manual wiring is required. Installation takes minutes; the real effort is DocuSign-side provisioning.
- Which Laravel and PHP versions does laravel-docusign support?
- Release 6.5.0 added Laravel 13 support and widened the underlying DocuSign REST client constraint to ^6, and the package targets Laravel 10, 11, 12 and 13 on modern PHP with Composer 2. The Laravel 13 path implies a higher PHP floor, so check composer.json before bumping your runtime image or CI matrix. Because the adapter tracks Laravel majors and SDK majors at the same time, treat the newest framework major as the least-exercised code path.
- How does authentication with the DocuSign eSignature API work in this package?
- You provision an integration key, an RSA keypair and JWT grant consent for each impersonated user on the DocuSign side, then let the package's config-driven credentials bind to the account and resolve the base URI. A competent Laravel engineer can typically reach a working sandbox envelope flow in one to two days, and the JWT consent loop is where schedules usually slip. Expect the effort to be mostly DocuSign configuration rather than Laravel code.
- Does laravel-docusign verify DocuSign Connect webhook signatures?
- No. The package is designed as a thin adapter that exposes SDK DTOs and SDK exceptions, and it does not add its own webhook verification layer, so validating Connect signatures and payload shape stays in your application code. Plan that into your build scope: capture the raw request body in a controller, verify it, then dispatch a queued job. This is one of the questions worth confirming with the maintainer before you commit to a schedule.
- Can I use laravel-docusign for multi-tenant apps where each tenant has its own DocuSign account?
- Not cleanly. The config layer is effectively single-account per application instance, so multi-tenant use requires runtime config swapping, which is fragile in long-running workers and queued jobs. If you need per-tenant credentials, wrap the package behind your own service that builds the client per tenant, or call the DocuSign SDK directly for that path. It is also not a fit for Lumen or non-Laravel PHP services.
- Should I use laravel-docusign or the official DocuSign eSignature PHP SDK directly?
- The wrapper gives you a service provider, a DocuSign facade, config and .env conventions, plus light helpers for envelopes, templates, brands and clickwraps, which is boilerplate you no longer have to own. It deliberately does not abstract the vendor domain, so you still work with SDK DTOs and SDK exceptions either way. If your app already calls the SDK directly, moving to the package is largely mechanical, and it slots cleanly into the container.
- How do I send an envelope or set up embedded signing with this package?
- Resolve or inject the DocuSign facade and call the envelope, template, brand or clickwrap helpers, which return SDK objects you pass on to the eSignature API. Envelopes are referenced by ID and templates by template ID, and embedded signing uses the recipient view flow exposed by the underlying SDK. Keep every one of these calls inside a single application-level gateway so a future package fork or SDK major bump stays a one-file change.
- Is laravel-docusign safe to use in production if it is community-maintained by a small contributor base?
- The dominant technical risk is bus factor, not code quality: the package is community-maintained with a narrow contributor base. Mitigate it by pinning versions explicitly, wrapping the facade in your own interface that returns your own DTOs and throws your own exceptions, and tracking DocuSign API deprecations, rate limits and OAuth policy changes yourself. Vendor-side risk exists regardless of which wrapper you choose.
- How do I test a DocuSign integration without sending real envelopes?
- Use a DocuSign developer sandbox account and keep the integration key, account ID and keys in your .env or a dedicated test config. Because the package returns raw SDK DTOs and throws SDK exceptions, the cleanest seam is your own gateway interface, which you can bind to a fake in the container for feature tests. That keeps your suite fast and stops it from hitting the DocuSign API on every run.
- What changed in version 6.5.0 and should I pin the DocuSign REST client version?
- 6.5.0 is an additive compatibility release: it adds Laravel 13 support and widens the underlying REST client constraint to ^6, with no removed config keys, renamed options or signature changes announced. The widened range is not free, because your lockfile can resolve to either SDK major depending on other constraints, so pin an explicit version and check for known-bad releases. Read it as a compatibility release rather than a rewrite.