Targito Api Bundle Laravel Package

Getting Started

• Check what you actually need first. This is a Symfony bundle, not a Laravel package. In a Laravel app the bundle's TargitoApiBundle class, DependencyInjection/Configuration.php, and Resources/config/services.xml are dead weight — Composer will install them, but nothing auto-registers. You will almost certainly consume the underlying targito/targito-api-php client directly and write a ~20-line service provider around it.
• Read the bundle's DependencyInjection/Configuration.php before installing. It is the only source of truth for config keys (API key, account/workspace identifier, base URL/sandbox flag). The README is thin and the repo is effectively unmaintained (last release 2021-05-07, 0 stars, 0 dependents), so treat the code as the documentation.
• Install and vendor-dive:

  composer require targito/targito-api-bundle
  ls vendor/targito/targito-api-bundle/src
  ls vendor/targito/targito-api-php/src   # the actual client you'll use
  

• Symfony path (if you're actually in Symfony): register in config/bundles.php, then configure in config/packages/targito_api.yaml with env vars:

  targito_api:
      api_key: '%env(TARGITO_API_KEY)%'
      # account/workspace/base_uri per Configuration.php
  

• Laravel path:

  // config/services.php
  'targito' => [
      'api_key' => env('TARGITO_API_KEY'),
      'account' => env('TARGITO_ACCOUNT_ID'),
  ],
  

  // app/Providers/TargitoServiceProvider.php
  $this->app->singleton(\Targito\Api\TargitoClient::class, fn ($app) =>
      new \Targito\Api\TargitoClient(config('services.targito.api_key'))
  );
  

  (Adjust the constructor signature to whatever vendor/targito/targito-api-php/src exposes — it is likely a Guzzle-based client taking an API key and optional GuzzleHttp\ClientInterface.)
• First use case to wire up: new user registration → add contact to a Targito list. Do it in a queued listener, not in the registration request, so a Targito outage never blocks signup. Once that round-trips in staging against a sandbox key, expand to campaigns/transactions.

Implementation Patterns

• Wrap the SDK in one domain service. Never inject the third-party client into controllers/jobs directly. Create App\Services\Targito\TargitoGateway with intent-revealing methods (subscribe(string $email, array $attributes), unsubscribe(), sendTransactional()). When you eventually fork or replace the SDK (plan for it), you change one file.
• Queue everything outbound. API calls are network I/O with a vendor you don't control. In Laravel use a ShouldQueue listener or a dedicated SyncContactToTargito job with $tries = 3, backoff() of 10/60/300s, and a failed() that logs and alerts. In Symfony, the Messenger equivalent.
• Event-driven sync for the happy path. Registered, ProfileUpdated, OrderPlaced → listener → job → gateway. Keep the mapping (Laravel model → Targito attributes) in a small mapper class so field renames are one-line changes.
• Batch/backfill as an artisan command, not a request. A targito:backfill-contacts command that chunks User::query()->chunkById(500, ...), dispatches jobs, and is safe to re-run (idempotent upserts by email). Never loop N users inside one job — you'll hit timeouts and lose the whole batch on one bad record.
• Config-driven multi-account. If you run staging, sandbox, and production lists, resolve the client from config at runtime (app(TargitoClient::class) bound per env) rather than hardcoding list IDs. Keep list/campaign IDs in config/targito.php, not scattered as magic strings.
• Testing. Bind a fake gateway in the container for feature tests ($this->app->instance(TargitoGateway::class, new FakeTargito)), and assert Bus::assertDispatched(SyncContactToTargito::class) after registration. For unit tests of the gateway itself, inject a mocked GuzzleHttp\ClientInterface / PSR-18 client and assert on the request URI and JSON body — do not hit the real API in CI.
• Extension point (Symfony): alias the bundle's service to your own implementation, or decorate it, rather than editing vendor. In Laravel, the service provider binding is the extension point — bind the SDK client only inside the provider, so swapping to a fork is a one-line use.
• Logging. Add a Guzzle middleware (or PSR-18 decorator) that logs method, path, status, and latency at debug, and request body at debug only with the API key redacted. This is your only real observability with an unmaintained vendor.

Gotchas and Tips

• This package is effectively abandoned. Last release May 2021, zero stars, zero dependents. Pin the exact version in composer.json (no ^), commit composer.lock, and assume no upstream bug fixes. Budget for forking targito/targito-api-php into a VCS repository the day the API changes or a dependency conflicts.
• Dependency conflicts are the most likely install failure. An old Guzzle/PSR-18 constraint from 2021 may clash with Laravel's current guzzlehttp/guzzle or symfony/http-client. If composer require fails, don't --ignore-platform-reqs your way through it — fork the SDK, loosen the constraint, and test.
• The bundle does nothing in Laravel. No package discovery, no service provider, no facade, no config publishing. If you expected php artisan vendor:publish, it doesn't exist. Expect to hand-write all wiring.
• Symfony config caching + env vars. In Symfony, %env()% inside certain bundle config nodes is resolved at container compile time; after changing .env in a cached deployment you must bin/console cache:clear. In Laravel, php artisan config:cache will bake the key in — re-run it after rotating TARGITO_API_KEY.
• Secrets. The API key is a full account credential. Keep it in .env / a secrets manager, never in config/targito.php defaults, and add key redaction to your logging middleware before you ship.
• Timeouts and retries aren't free. The 2021-era client likely defaults to Guzzle's no-timeout behaviour. Set an explicit connect/read timeout (e.g. 3s/10s) on the injected client, and implement retries in your job layer ($tries/backoff) rather than trusting the SDK — retrying inside a request thread will hang your app.
• Errors are probably exceptions, not result objects. Wrap every gateway call in try/catch for the SDK's exception type and a broad Throwable, and decide explicitly per call whether failures are fatal (transactional send) or best-effort (marketing list sync — swallow and log).
• Idempotency by email. Targito upserts on contact email in most marketing flows; make your jobs idempotent on that key so retries and backfills don't duplicate contacts. Deduplicate batch imports before sending.
• Debugging checklist when a call silently no-ops: (1) is the queued job actually running (php artisan queue:work)? (2) is the API key the sandbox one — sandbox writes don't appear in production lists; (3) log the raw response body — some marketing APIs return HTTP 200 with an error payload; (4) check whether the SDK swallows non-2xx into a boolean.
• Fork readiness. Because there are no dependents and no maintainer, keep your gateway's public surface tiny and framework-agnostic. That is your real insurance policy: replacing targito/targito-api-* with a hand-rolled Guzzle client should be an afternoon, not a rewrite.