Weave Code
Laravel Onoffice Adapter Laravel Package
innobrain/laravel-onoffice-adapter
Laravel adapter for the onOffice API that makes it easy to connect your PHP application to onOffice CRM data, including real estate listings, contacts, and addresses, through a clean, framework-friendly integration layer.
innobrain/laravel-onoffice-adapter is a Laravel package that integrates the OnOffice real estate API into your application, giving you a clean, idiomatic interface for working with property data. It wraps the raw API in Laravel-friendly abstractions, so you can query estates, addresses, and related records without hand-crafting requests.
- Eloquent-style access to OnOffice estate and address data
- Configurable API credentials and connection settings via Laravel config
- Query builder for filtering, sorting, and paginating results
- Seamless integration with the Laravel service container and facades
- Publishable configuration and migration-ready models for rapid setup
Frequently asked questions about Laravel Onoffice Adapter
- How do I install and configure innobrain/laravel-onoffice-adapter in a Laravel app?
- Install it with Composer using the innobrain/laravel-onoffice-adapter package name, then publish the package's config file with the vendor:publish command. The package ships a Laravel service provider and a publishable config file, so the wiring itself is standard Laravel. Put your onOffice API token, secret, and any tenant-specific identifiers in your .env file and reference them from config, never hardcoded in the repository. Because credentials are long-lived secrets, store them in your secret manager and inject them at deploy time rather than committing them.
- Which Laravel and PHP versions does laravel-onoffice-adapter support?
- The package is a thin Laravel integration, so its composer.json illuminate/* and php constraints are the authoritative answer, and you should read them before adopting it. There is no widely documented supported-version matrix or public CI badge to rely on, so verify against your target Laravel and PHP release rather than assuming. Pin the package to an exact minor version and commit your lock file, since with zero dependents the constraints are unlikely to have been battle-tested against your stack.
- Does this package wrap the official onOffice SDK or implement HMAC signing itself?
- The adapter handles the onOffice contract for you, including the HMAC-signed request flow built from token, secret, and timestamp, but the overview does not state whether it delegates to the official onOffice SDK underneath. Read the source of the client class before adoption so you know who owns the signing and transport code and how quickly a fix would land. That matters because a signing regression breaks every request, not just one endpoint.
- Should I call innobrain/laravel-onoffice-adapter directly from controllers and models?
- No. Treat it as an outbound adapter at the edge of a domain boundary and consume it behind your own repository or gateway interface. onOffice's module and field vocabulary, including German field names for estate, address, and relation, should not leak into your domain models. Registering the facade only inside your infrastructure layer keeps a future upgrade, patch, or replacement a one-file change plus tests.
- How does laravel-onoffice-adapter handle API errors and error codes?
- The package does not document a published error taxonomy, so inspect the client code to see whether failures surface as typed exceptions, result objects, or null and false returns. Whatever the raw behaviour is, translate it in your gateway into your own exception types so callers are not coupled to onOffice specifics. Log the upstream error code and message for support cases, because onOffice diagnostics are hard to reconstruct after the fact.
- Does the adapter support pagination, listlimit, and result counts out of the box?
- onOffice reads use filter and listlimit semantics, and the package exposes that style of querying, but you should confirm whether it returns result counts and handles offset looping for you or expects callers to iterate. If paging is manual, wrap it in a single gateway method that loops until the reported total is reached and enforces a sane page size. Test against a tenant with a large estate list early, because paging bugs usually only appear past the first page.
- Can I use Http::fake() to test code that uses laravel-onoffice-adapter?
- That depends on whether the adapter uses Laravel's HTTP client or talks to Guzzle directly, which the overview does not specify. If it goes through Laravel's client, Http::fake works and your feature tests stay fast and offline. If not, you will need to mock the client class or bind a fake implementation behind your own gateway interface, which is another argument for wrapping the package.
- Which onOffice modules does the package cover, and can I call unsupported actions?
- Property and contact data access is the core focus, with estate, address, and relation records called out explicitly. Support for create, modify, and delete actions and for less common modules may be partial, so check the client API before designing write flows. If you need a raw action pass-through for an unsupported module, verify it exists, otherwise you will end up hand-rolling an HTTP call anyway.
- How should I handle writes and throttling when using this adapter in production?
- Start read-only, then add writes only once you have idempotency keys and reconciliation tooling. Retries, throttling, and partial batch failures are the kind of edge-case behaviour that tends to be pushed onto the consumer in a thin adapter, so implement backoff and rate limiting in your gateway rather than assuming the package does it. Because adoption is low and the package is effectively vendor-maintained, also subscribe to repository releases so an onOffice API change does not surprise you in production.
- Is innobrain/laravel-onoffice-adapter a safe alternative to writing my own onOffice client?
- It is a good fit for a Laravel-first team that wants to skip the boilerplate of signing and transport, and it is small enough to replace if needed. The trade-off is that it has few dependents and a single organisational maintainer, so treat it as an internal dependency with an external name. If you already have a bespoke client, migrate incrementally by running both implementations in shadow mode against read paths, diffing outputs, and cutting over reads before writes.
Weaver
How can I help you explore Laravel packages today?