Dao Bundle Laravel Package

Getting Started

1. Install the bundle and its SDK dependency

composer require setono/dao-bundle

The bundle is a thin Symfony integration around the underlying DAO PHP SDK (setono/dao-php-sdk or similar). Confirm both packages land in composer.json — the SDK is what you'll actually spend most of your time reading.

2. Register it

If you use Symfony Flex, the bundle is likely auto-registered via the generated config/bundles.php entry (Setono\DAOBundle\SetonoDAOBundle::class). On older apps without Flex, add it manually.

3. Configure credentials

Look for a config file the Flex recipe would place at config/packages/setono_dao.yaml. Expect something like:

setono_dao:
    # api credentials — check the SDK's Client constructor for exact keys
    username: '%env(DAO_USERNAME)%'
    password: '%env(DAO_PASSWORD)%'
    # likely a sandbox/test toggle
    sandbox: '%kernel.debug%'

If no recipe exists (very likely for a 1-star package), define the config yourself by reading DependencyInjection/Configuration.php in the bundle source — that file is the ground truth for every available option.

4. Where to look first

• vendor/setono/dao-bundle/src/DependencyInjection/ — service definitions tell you exactly what gets registered and under which service ID.
• vendor/setono/dao-php-sdk/src/ — the actual API surface. The bundle wraps it, so every method you call comes from here.
• vendor/setono/dao-bundle/src/SetonoDAOBundle.php — the entry point, usually short.

5. First use case

The most common reason to pull this in is creating a shipment and getting a label back:

// inject the client the bundle exposes — verify the service ID in services.xml
public function __construct(private ClientInterface $daoClient) {}

public function book(): void
{
    $shipment = Shipment::create()
        ->setRecipient(/* ... */)
        ->setParcel(/* ... */);

    $result = $this->daoClient->createShipment($shipment);
}

Adapt the DTO names to whatever the SDK actually ships — they won't match this exactly, but the shape will be similar.

Implementation Patterns

Wrap the SDK behind your own adapter

Because the bundle is a thin wrapper, don't scatter ClientInterface calls through controllers and message handlers. Define a ShipmentGateway interface in your domain and implement it once against the DAO client. This gives you a single seam to mock in tests and a single place to patch when the SDK changes (which, given the release cadence, it will).

final class DaoShipmentGateway implements ShipmentGateway
{
    public function __construct(private ClientInterface $client) {}

    public function book(Order $order): ShipmentReference
    {
        // map your domain to SDK DTOs here
    }
}

Push API calls into Messenger messages

Shipping APIs are slow and rate-limited. Dispatch a BookShipment message from your checkout flow, handle it in a worker, and let Symfony Messenger's retry + failure transport handle transient 5xx responses. This also keeps your HTTP request cycle fast.

#[AsMessageHandler]
final class BookShipmentHandler
{
    public function __invoke(BookShipment $message): void
    {
        $this->gateway->book($message->order);
    }
}

Use http_client decoration for observability

The PHP SDK almost certainly builds on symfony/http-client or an injected ClientInterface. In Symfony you can decorate the SDK's underlying transport to log requests/responses, or reuse the bundle's own client service if it's autowirable. Wire a LoggerInterface and a Profiler-friendly middleware in dev; strip it in prod.

services:
    App\Http\LoggingClient:
        decorates: 'setono_dao.http_client'  # verify the actual service id
        arguments: ['@.inner', '@logger']

Testing: mock at the boundary, not the bundle

Don't try to instantiate the bundle in unit tests. Depend on your ShipmentGateway interface in domain code and use a fake in tests. For integration tests that genuinely exercise the SDK, point the bundle's sandbox (or base_uri) option at a wiremock/httpbin endpoint if the config exposes one — check Configuration.php.

Configuration via env vars, one per environment

Keep credentials in .env.local and reference them through %env(...)% in the bundle config. If the bundle exposes a sandbox: flag, default it to %kernel.debug% so dev never accidentally creates real labels.

Gotchas and Tips

This package is essentially abandonware-adjacent. Last release October 2023, 1 star, 0 dependents. Treat it as a starting point, not a dependency you can lean on for support. Pin the exact version in composer.json and be prepared to fork or copy the service definitions if a Symfony upgrade breaks it. A bundle this size is often simpler to inline into src/ than to depend on.

Read Configuration.php before writing YAML. With no docs and no recipe, the bundle's Configuration.php is the only reliable reference for option names, defaults, and whether a sandbox mode exists. Guess-and-check against a real API is a fast way to create real shipments.

Service IDs are not autowirable by default in older bundles. If ClientInterface can't be autowired, check Resources/config/services.xml (or services.yaml in src/) for the concrete ID and bind it explicitly:

services:
    App\…\DaoShipmentGateway:
        arguments: ['@setono_dao.client']

Watch Symfony version constraints. A 2023 bundle may cap at Symfony 6.x or even 5.x in its composer.json. If you're on 7.x, resolution will fail; either fork and relax the constraint, or vendor the handful of service definitions manually. This is usually a five-minute patch but it's the most common reason installs fail on a modern app.

Credentials in the wrong place. Some Setono bundles expect credentials via constructor arguments rather than bundle config. If YAML options are silently ignored, open DependencyInjection/SetonoDAOBundleExtension.php and see what's actually being read.

No events means no hooks. Unlike larger bundles, you probably won't get Symfony events like ShipmentCreatedEvent. If you need post-creation behaviour (webhooks, notifications), wrap the gateway (see Implementation Patterns) rather than expecting extension points that don't exist.

Log every request/response body in non-prod. Shipping APIs return useful error payloads (invalid postcode, unknown service point) that don't always map cleanly to exceptions. Decorate the HTTP client with a logger during development so you can see the raw response when a call fails — the exception message alone often won't tell you which field was rejected.

Test against the sandbox, but verify it exists. Some Setono SDKs use sandbox: true to swap a base URI; others expect separate credentials. Confirm in the SDK's client factory which mechanism applies, and add an assertion (or a hard guard in the adapter) that prevents production credentials from being used in dev.