- Is ets/echosign-bundle a Laravel package?
- No. It is a Symfony bundle built around Symfony kernel registration, config.yml, and dependency injection conventions. Laravel applications will not get package discovery, a service provider, or a facade from it.
- Can I use ets/echosign-bundle in a Laravel application?
- You can install it via Composer, but integration is not Laravel-native and is low-to-medium feasibility. You would need to bridge Symfony bundle configuration and services manually or use it only as a reference for SOAP call shapes. For production Laravel code, prefer an internal adapter around a supported Adobe Sign API.
- How do I install ets/echosign-bundle?
- Install with Composer using composer require ets/echosign-bundle. The README recommends dev-master, which is a reproducibility and supply-chain risk; avoid dev-master for production. PHP SOAP support and EchoSign or Adobe Sign API credentials, gateway URL, and WSDL URL are required.
- Which Laravel and PHP versions does ets/echosign-bundle support?
- The package is a Symfony bundle and does not declare Laravel version support. Its likely older Symfony and PHP constraints may conflict with modern Laravel and PHP 8.x, so check composer.json before committing. There is no official Laravel compatibility matrix.
- How do I configure API credentials and recipients in ets/echosign-bundle?
- Configuration uses Symfony config.yml under ets_echo_sign with api.key, api.gateway, api.wsdl, a recipients email list, and an optional debug prefix. Laravel does not consume config.yml natively, so you would need custom bridging. Keep credentials in environment or secret management and rotate them.
- What Adobe EchoSign API does ets/echosign-bundle wrap?
- It wraps the legacy EchoSign SOAP API, specifically EchoSignDocumentService16. Adobe Sign has moved toward REST APIs, so this endpoint may be deprecated or account-limited. Verify that your Adobe Sign contract still permits DocumentService16 before building on it.
- Does ets/echosign-bundle include a Laravel service provider or facade?
- No. There is no Laravel service provider, facade, package discovery, or publishable config. It assumes Symfony kernel registration and Symfony dependency injection conventions. Laravel developers must write their own integration layer or avoid the bundle.
- Is ets/echosign-bundle maintained and safe for production?
- Adoption is very low, with only a few stars and zero dependents, and the badges reflect historical CI rather than current support. The wrapper is thin and undocumented, which is risky for e-signature audit trails, PII, and credential handling. Treat it as high risk and isolate or replace it behind an internal interface.
- Are there tests or current CI for ets/echosign-bundle?
- The README shows Travis, Scrutinizer, and SensioLabsInsight badges, but these indicate historical CI rather than active maintenance. The context does not confirm current tests or supported CI. Run your own sandbox spike and contract tests before relying on it.
- What should Laravel teams use instead of ets/echosign-bundle for Adobe Sign?
- Prefer Adobe Sign's supported REST API and official SDKs, wrapped in a Laravel service provider and internal ESignatureGateway contract. If needed, use the bundle only as a reference for SOAP call shapes, not as a domain dependency. This keeps document send, status, signing URL, download, void, and audit metadata behind a replaceable interface.