- How do I install and configure wetcat/fortie in a Laravel application?
- Add it with composer require wetcat/fortie, register the service provider if your Laravel version does not auto-discover it, and publish the config file with php artisan vendor:publish. Fortnox credentials for your registered app belong in the published config or in .env so they stay out of version control. After that you complete the Fortnox OAuth2 authorization flow and persist the returned tokens before making your first API call.
- Which Fortnox API endpoints and version does Fortie cover?
- Fortie is a wrapper around the Fortnox REST API for accounting and ERP data such as customers, invoices, and vouchers, but you should read the source to confirm which endpoints are actually implemented for the API version you need. Look for a generic request method or escape hatch so uncovered endpoints can be called without forking. If a required endpoint is missing, extending the package is usually cheaper than running a second integration path.
- How does Fortie handle Fortnox OAuth2 access and refresh tokens?
- Fortnox uses OAuth2 with per-tenant authorization plus refresh tokens, so something must store access tokens, refresh them before expiry, and handle re-authorization when a customer revokes access. Whether Fortie owns that lifecycle or expects your application to do it is the first thing to confirm in the source. If persistence is left to you, budget for it up front rather than discovering the gap in production.
- Does wetcat/fortie support multiple Fortnox tenants in one Laravel app?
- Do not assume multi-tenant isolation: every Fortnox customer authorizes your integration separately, so you need a token per tenant and a reliable way to select the right client per request. Check whether the package allows per-connection configuration or only a single global credential set. If it is global-only, wrap it or instantiate one client per tenant in your own service layer.
- Which Laravel and PHP versions does wetcat/fortie support?
- The package is described as a Laravel 5-era integration, which matters if your baseline is Laravel 9, 10, or 11. Check composer.json for Illuminate component and PHP version constraints, and note the Guzzle major version for conflicts with your other dependencies. If the constraints are stale, a fork with updated requirements is usually a small, contained change.
- Is wetcat/fortie actively maintained, and what is the bus factor risk?
- It has a small footprint, roughly 19 GitHub stars and no dependents, and a single commercial maintainer, so the bus factor is effectively one. Fortnox continues to evolve its API and rate-limit model, and an unmaintained wrapper decays quickly. Pin the version, track upstream commits, and keep a contingency budget for a fork or in-house replacement.
- How does Fortie deal with Fortnox rate limits, pagination, and failed writes?
- Fortnox enforces rate limits and returns errors that must be handled deliberately, and retry and 429 behavior in this package is unverified, so read the client code before trusting it. Check whether failures surface as typed exceptions or opaque responses, and whether list endpoints paginate automatically. Add your own retry and backoff layer around the client before going live.
- Can I test Fortie against a Fortnox sandbox tenant before going live?
- Yes: register an app in the Fortnox Developer Portal, point it at a sandbox tenant, and complete the OAuth flow plus one read call before touching production data. That proof of concept is the fastest way to confirm endpoint coverage, token handling, and error behavior. Also confirm that your app registration model matches how your customers will authorize you.
- Is Fortie related to Laravel Fortify, or is it an accounting integration?
- Despite the similar name, wetcat/fortie is a Laravel wrapper for the Fortnox accounting API, not an authentication UI built on Laravel Fortify. If you need login, registration, and password reset scaffolding, this is the wrong package. The naming overlap is coincidental; the purpose here is invoicing, customer, and voucher data exchange.
- Should I call Fortie directly or wrap it behind my own client interface?
- Wrap the package behind your own FortnoxClient interface and inject it, so domain code never calls the vendor API directly. That keeps you portable if the maintainer stalls and lets you swap or fork the package without rewriting business logic. It also gives you a single place to add token handling, retries, and logging.