Weave Code
Sdk Laravel Package
target365/sdk
PHP SDK for Target365’s messaging platform, making it easy to send SMS and RCS messages, manage contacts and subscriptions, and handle delivery reports from Laravel or any PHP app via a clean, PSR-compatible API.
Target365 SDK for PHP
Frequently asked questions about Sdk
- How do I install target365/sdk in a Laravel app?
- Install it with composer require target365/sdk. The package is framework-agnostic, so there is no Laravel service provider to register and no config file to publish. In Laravel, create a small adapter class, bind it in a service provider or the container, and inject that adapter where you send messages.
- Is target365/sdk a Laravel package or a framework-agnostic PHP SDK?
- target365/sdk is a framework-agnostic PHP SDK, not a Laravel package. It does not ship a service provider, facade, or config publishing pattern. That is fine for Laravel if you wrap it in your own Target365Client adapter and keep the vendor namespace out of domain code.
- Which PHP and Laravel versions are compatible with target365/sdk?
- The SDK does not declare Laravel-specific constraints because it is framework-agnostic, so compatibility depends on its PHP version constraint and HTTP client dependency. Check that the declared PHP range admits your Laravel runtime, such as PHP 8.2 or 8.3, and that its Guzzle or PSR-18 requirement does not conflict with Laravel 12. Run composer why-not target365/sdk after adding it to surface conflicts early.
- How do I configure Target365 API credentials in Laravel?
- Put Target365 credentials in config/services.php using TARGET365_* environment variables and keep the actual secrets in your secret store. The SDK has no Laravel config file to publish, so your adapter should read from Laravel config rather than calling env() directly. If you serve multiple brands, resolve credentials per tenant in the adapter factory.
- Can target365/sdk send SMS, MMS and RCS messages?
- Yes. The SDK is designed for Target365 messaging resources, including SMS, MMS and RCS, plus related delivery and content endpoints. In Laravel, expose separate adapter methods for outbound send and delivery reports so vendor specifics stay at the edge. Verify RCS capability flags and sender restrictions against the API before enabling them per brand.
- Does target365/sdk verify webhook signatures for delivery reports?
- The package overview does not document webhook payload verification, so assume you must validate inbound delivery-report callbacks yourself. Treat the SDK as an outbound and resource client, and add signature or shared-secret validation in your Laravel webhook controller. Confirm the exact Target365 callback authentication scheme with the vendor before going live.
- How does target365/sdk handle API errors and retryable failures?
- The SDK provides structured request and response handling with error exceptions, but you should verify whether it distinguishes retryable 429 and 5xx failures from terminal 4xx errors. Wrap the SDK calls in your adapter and map its exceptions to your own domain errors. Add bounded retries only for retryable failures, and log the raw vendor response for diagnosis.
- Does target365/sdk support idempotency keys to prevent duplicate SMS on retries?
- The package context does not confirm support for idempotency keys on send, which matters if queue retries could duplicate SMS. Check the SDK send methods and Target365 API documentation for an idempotency header or client reference field. If it is missing, enforce deduplication in your queue or adapter layer, or call the REST endpoint directly when you need that control.
- How do I test Laravel code that uses target365/sdk?
- Depend on your own MessageGateway interface rather than the vendor client, then bind a fake or stub implementation in Laravel tests. Because there is no service provider, you can swap the Target365 adapter for an in-memory fake in the container without network calls. Keep a small contract test suite against the real client only for adapter behavior, not for every domain test.
- Is target365/sdk actively maintained, and should I use it or call the REST API directly?
- The SDK is single-vendor maintained, has low adoption, and had a release in March 2025, so it is alive but carries vendor concentration risk. For a handful of endpoints, a small internal client built on Laravel's Http facade may remove the dependency and give you clearer control over webhook validation and idempotency. Either way, adopt it behind an internal interface so a future swap is contained.
Weaver
How can I help you explore Laravel packages today?