- What is splash/optilog and what does it actually do?
- splash/optilog is an embedded REST API connector from the Splash connector family that wraps the Optilog logistics and transport management API. Despite some marketing copy describing it as a logging package, its real purpose is to let a PHP application call Optilog endpoints for orders, shipments, and related logistics data. It is a thin adapter rather than a full integration platform, so you supply credentials and handle the business logic yourself.
- Is splash/optilog a Laravel package?
- Not in the conventional sense. There is no evidence of a Laravel service provider, facade, publishable config file, or Laravel version constraint, so treat it as a plain PHP library that happens to run inside a Laravel application. You would typically bind it behind your own interface in the domain layer rather than relying on framework auto-discovery.
- How do I install splash/optilog with Composer?
- The package is hosted on GitLab rather than Packagist, so a plain composer require will probably not resolve it on its own. Add a VCS repository entry pointing at https://gitlab.com/splash-connectors/Optilog-Bundle and require the package, supplying a GitLab token if the repository is private. Pin the dependency to a specific commit in composer.lock, since no release tags or semantic versioning guarantees are visible.
- Which PHP and Laravel versions does splash/optilog support?
- The available metadata does not publish a supported PHP or Laravel version matrix. Before adopting, read composer.json for the php constraint and any framework requirements, and run your own compatibility check against your target runtime. Given the absence of a declared matrix, treat version support as unverified rather than assuming it tracks current Laravel releases.
- Does splash/optilog depend on other Splash framework packages at runtime?
- That is the biggest architectural question and the first thing to verify in composer.json and the top-level src directory. If the connector is a self-contained HTTP client with DTOs and endpoint methods, it can sit cleanly behind an interface in your domain layer. If it inherits Splash base classes and expects Splash's container, config tree, and entity mapping conventions, you inherit the whole Splash framework as a transitive dependency, which is usually unacceptable inside a Laravel product.
- Is there Optilog API documentation or a sandbox account available?
- The repository metadata shows no README guidance, no published API documentation, and no example usage. Integration realistically depends on getting a Splash-authored sandbox account and credentials for Optilog. Without a sandbox you would be coding against an undocumented French logistics API using only the package's method signatures as a specification.
- How does splash/optilog handle errors, retries, and rate limits?
- Nothing in the available information specifies retry policy, rate-limit handling, idempotency keys, or partial-failure reporting. REST connectors in the Splash family typically throw on non-2xx responses and return arrays, but that behavior is not confirmed here. For a logistics API where duplicate order submissions can create real duplicate shipments, verify idempotency semantics before going live.
- Is splash/optilog safe to use in production?
- Treat it as high risk until audited. The connector handles Optilog authentication and transmits order, shipment, and likely customer data, so review token storage, payload logging, and TLS verification before production use. Zero stars, zero dependents, and no public issue activity mean you would be the first known integrator, so plan for defensive wrapping, timeouts, and monitoring.
- How actively is splash/optilog maintained, and what if Splash abandons it?
- The package is single-vendor and single-team owned, with no visible release tags, version history, or public issue tracker activity. If Splash deprioritizes the connector, you fork and maintain it yourself, including keeping pace with Optilog API changes you cannot see. Budget for that maintenance burden, or prefer a documented alternative if one exists.
- How should I test a Laravel application that uses splash/optilog?
- Wrap the connector behind your own interface and inject a fake in tests so your application code never calls Optilog directly. For integration coverage, use an Optilog sandbox if you can obtain credentials, and assert on idempotency, timeout, and error-path behavior explicitly. Keep a thin adapter layer so you can swap the library or a hand-rolled Guzzle client later without touching domain code.