Mindbaz Bundle Laravel Package

Getting Started

This is a Symfony bundle wrapping the Mindbaz email-marketing API, not a Laravel package. For a Laravel developer the realistic options are (a) use it inside a Symfony app you also maintain, or (b) skip the bundle and call the underlying Mindbaz client/API directly from a Laravel service — which is usually what you want, since the bundle itself is just DI wiring plus config.

If you are in the Symfony context:

1. composer require kozikaza/mindbaz-bundle (expect this to fight you on modern PHP — see Gotchas).
2. Register the bundle in app/AppKernel.php (Symfony 2/3 era) or config/bundles.php.
3. Configure credentials under kozikaza_mindbaz in config/config.yml — typically login, password, and the API url/endpoint, plus any default channel or group identifiers.
4. Check vendor/kozikaza/mindbaz-bundle/DependencyInjection/Configuration.php first — that file is the authoritative list of config keys for this version, and it's the single best place to confirm service names and parameter shape.
5. Inject the registered service into a controller or command and make one call — adding an email to a list — to validate connectivity.

First use case: hook the subscribe call into your user-registration flow (or a newsletter signup form handler) and confirm the contact appears in Mindbaz. That single end-to-end path is worth more than reading the README, because the docs are thin and the API surface drifts between Mindbaz versions.

Implementation Patterns

Wrap it, don't sprinkle it. The bundle's service is a thin client. Put it behind your own NewsletterGateway interface and bind the Mindbaz implementation to it. This buys you: easy mocking in tests, a clean swap if you migrate to Mailchimp/Brevo, and a place to normalize Mindbaz's quirks so they don't leak into controllers.

Subscriber lifecycle hooks. The natural integration points:

• On user create → subscribe (single or double opt-in depending on your config/compliance needs).
• On profile update → update contact fields.
• On account delete → unsubscribe or hard-delete the contact.

In Laravel terms these are model events or queued listeners; in Symfony, kernel/Doctrine events. Either way, do not call the API synchronously in the request — Mindbaz calls are network round-trips and the old API is not fast.

Queue everything. Push subscribe/unsubscribe/update into a job or command and retry with backoff. Mindbaz rate-limits, and a slow API should never block a registration form. Batch bulk imports into a console command that iterates in chunks (500–1000) with a pause between batches.

Field mapping is your real work. Mindbaz expects custom fields with specific names/types that you define in the Mindbaz UI. Build an explicit mapping array (local_field => mindbaz_field) in config and validate it at startup. This is where 80% of integration bugs live — mismatched field names silently drop data or throw opaque errors.

Campaign/testing flows. If the bundle exposes campaign creation, keep it to internal tooling (artisan/console commands, an admin panel) rather than user-facing code. Test sends should target a dedicated test group, not your production segment.

Idempotency. Store the Mindbaz contact ID (or email + list as a composite key) alongside your user record. That gives you a cheap "already synced?" check and lets you reconcile when a webhook or manual change happens.

Gotchas and Tips

• It's effectively abandoned. Last release April 2017, 2 stars, 0 dependents. It targets Symfony 2.x/3.x. On PHP 8 / Symfony 6+ expect composer conflicts in symfony/framework-bundle and symfony/dependency-injection constraints. You will likely need --ignore-platform-reqs or a fork. Budget for this; don't assume composer require just works.
• Zero community = zero answers. No Stack Overflow corpus, no recent issues. Your debugging loop is: read the bundle source, read Mindbaz's own (French-language) API docs, and test against a real account. Keep a sandbox/test list.
• Credentials in YAML. config.yml is committed. Move login/password to environment parameters (%env(...)% or .env), even on the old Symfony version — the bundle reads parameters, so the indirection is free.
• Protocol reality. Mindbaz's historical API is SOAP/XML-RPC-flavored, not clean REST. Errors arrive as fault strings, not HTTP status codes. Wrap every call in try/catch, log the raw request/response at debug level, and translate faults into your own exception types.
• Opt-in semantics matter legally. Confirm whether your configured flow is single or double opt-in before going live — GDPR/CAN-SPAM exposure if you get it wrong, and the bundle won't stop you.
• No async, no retry, no rate-limit handling in the bundle. All of that is yours to add. This is the biggest gap between "it works on my machine" and "it works in production."
• Extension points are limited to overriding the service definition (alias the bundle's service ID to your own class in services.yml) or decorating it. Prefer decoration over forking the bundle — you keep the config loading and gain your own behavior.
• Testing. Never hit the real API in tests. Mock the service at your gateway boundary. If you must integration-test, gate it behind an env flag and a dedicated Mindbaz sandbox account.
• Verdict for a Laravel team: treat this bundle as documentation of how to talk to Mindbaz, then write a ~200-line Laravel service class with an HTTP/SOAP client, a config file, and a queueable job. You'll spend less time than fighting 2017 Symfony constraints, and you'll own the code.