- What is lsv/rejseplan-php-api used for?
- It is a lightweight PHP client that wraps the Rejseplanen.dk public transport API, so you can query Danish journey plans, departures, arrivals, stops, and nearby locations from your own code. It is framework agnostic, meaning it works in plain PHP scripts as well as inside a Laravel application installed via Composer. You use it whenever your app needs live Danish transit data without hand-rolling HTTP requests and response parsing.
- How do I install lsv/rejseplan-php-api with Composer?
- Install it with composer require lsv/rejseplan-php-api, which pulls the package and its dependencies into your vendor directory. In Laravel the Composer autoloader is already wired up, so no extra registration step is required to start using the classes. If you are on plain PHP, just include vendor/autoload.php in your bootstrap file.
- Does this package work with Laravel, and is there a service provider or facade?
- The package is a plain PHP wrapper rather than a Laravel-specific integration, so there is no documented facade or auto-discovered service provider to rely on. In Laravel you simply instantiate the client classes directly or bind them into the container inside your own service provider. That keeps it flexible, but it does mean Laravel configuration and dependency injection wiring are your responsibility.
- Do I need an API key or credentials to use the Rejseplanen API?
- Access requirements depend on the Rejseplanen endpoints you call, and some routes expect authentication or identifying parameters. Check the package's constructor and configuration options, plus the current Rejseplanen API documentation, before going live. Store any credentials in your environment file rather than hard-coding them in source.
- Which Rejseplanen endpoints does this wrapper support?
- The wrapper covers the core Rejseplanen features: journey planning between locations, departures and arrivals for a stop, stop lookups, and nearby location searches. These map to the most common public transport use cases such as a departures board or a trip planner. If you need an endpoint that is not exposed, you can usually extend the client or call the API directly.
- How do I plan a journey between two stops with this package?
- You create the client, then call the journey or trip method with an origin and destination, which can typically be stop IDs or location names. The returned result contains legs, departure and arrival times, and transfer information you can render in your UI. Because Rejseplanen IDs are far more reliable than free-text names, resolving stops first is a good habit.
- How do I get live departures from a specific stop?
- Use the departures method with the stop ID, and optionally pass a limit or time window to narrow the result set. The response gives you line names, directions, and scheduled or expected times you can display on a board. Cache the output briefly, since departure data changes constantly and repeated calls add latency.
- What PHP version does lsv/rejseplan-php-api require?
- Exact version constraints are defined in the package's composer.json, so check that file or the Packagist listing before installing. Composer will refuse the install if your PHP version does not satisfy the requirement. In a Laravel app, also confirm the package is compatible with the framework version you run, since older Laravel releases pin older PHP versions.
- How should I handle errors, timeouts, and rate limits in production?
- Wrap client calls in try/catch blocks and treat network failures as expected rather than exceptional, because the Rejseplanen API is a remote service you do not control. Set sensible timeouts and add caching or short-lived caching for repeated queries such as a departures board refreshed every few seconds. Avoid aggressive polling loops, and degrade gracefully to cached or empty results when the upstream API is unavailable.
- Can I test code that uses this package without hitting the live Rejseplanen API?
- Since the wrapper talks to a remote HTTP API, tests that call it directly will be slow and flaky, so isolate it behind your own interface or adapter class. You can then swap in a fake implementation in Laravel's container or use your preferred HTTP mocking approach in PHPUnit. That keeps your test suite fast and independent of network availability and API rate limits.