Weave Code
Laravel Dynamics Client Laravel Package
justbetter/laravel-dynamics-client
A Laravel package that provides a fluent client for Microsoft Dynamics, making it easy to query, create and update records from your app. Includes configurable connections, authentication and a clean, Eloquent-like interface for working with Dynamics entities.
A package to easily use Microsoft Dynamics web services via OData with Laravel
Frequently asked questions about Laravel Dynamics Client
- How do I install and set up justbetter/laravel-dynamics-client in a Laravel app?
- Install it with Composer using composer require justbetter/laravel-dynamics-client, then publish the package config file with the vendor:publish command so you can edit the connection settings. Laravel's package auto-discovery registers the service provider and facade, so no manual wiring is usually needed. After that, populate your Azure AD app registration details (tenant ID, client ID, client secret) and the Business Central company or environment you want to target, ideally from your .env file.
- Does this package work with Microsoft Dynamics 365 Business Central or Dynamics 365 Sales?
- The package is a client for Microsoft Dynamics web services exposed via OData, which aligns with Dynamics 365 Business Central's OData v4 API surface. If you need the separate Dynamics 365 Sales or Customer Engagement Web API, confirm the endpoint and query conventions line up before committing, because that changes entity names, auth scopes and query patterns downstream. The safest approach is to verify the base URL and entity paths you intend to call against a sandbox tenant first.
- Which Laravel and PHP versions are supported by the 2.x release line?
- The 2.x line implies a modern Laravel baseline, generally the Laravel 10 and 11 era with PHP 8.1 or newer. Because exact constraints live in the package's composer.json, check that file (or run composer why-not justbetter/laravel-dynamics-client) against your application before upgrading. If your app is still on an older Laravel or PHP version, this package may force a framework upgrade as part of adoption.
- How do I configure authentication and credentials for the Dynamics connection?
- Authentication uses an Azure AD app registration, so you register an application in Azure AD, grant it the appropriate Business Central API permissions with admin consent, and then supply the tenant ID, client ID and client secret through the package configuration. Credentials should be read from environment variables or a secrets manager rather than committed to the config file, and you should keep separate app registrations per environment. Client secret expiry and conditional access policy changes are the most common cause of production outages with this kind of integration, so monitor expiry and rotate on a schedule.
- Can I configure multiple connections, for example a Business Central sandbox and production?
- The package is config-driven, so you can define separate connection entries for each environment and select which one a given request should use. Typical setups bind the active connection per environment via .env, with distinct app registrations and base URLs for sandbox versus production. Keeping credentials out of code and namespacing your connections makes it easy to point CI or local development at a non-production tenant.
- How do I query, create and update Dynamics records with the fluent client?
- The client exposes a fluent, Eloquent-like interface where you select an entity set, apply OData filters, selects and expansions, and then retrieve results as collections or arrays. The same interface supports creating, patching and deleting records by posting or patching payloads to the entity endpoint. Because this is an infrastructure layer rather than a domain model, the practical pattern is to wrap calls in your own repository or gateway class so business logic never imports the vendor namespace directly.
- What changed in version 2.1.0 and do I need to change my code?
- Version 2.1.0 is a patch release that fixes the empty JSON object body emitted for requests without parameters. OData endpoints and strict intermediaries can reject that stray {} payload, so the update mainly reduces spurious 400 responses on parameterless actions, deletes and other no-body calls. There are no breaking changes and no new public API, so upgrading from 2.0.x should be a drop-in composer update. If you previously passed a dummy parameter purely to avoid the empty body, that workaround can be removed, though leaving it in place is harmless.
- Does the client handle Business Central API throttling and 429 Retry-After responses?
- Business Central enforces per-user and per-tenant API limits and returns 429 responses with a Retry-After header when you exceed them. Confirm whether your installed version honors that header automatically; if it does not, implement a bounded retry policy in your own wrapper around the client. Only retry idempotent calls blindly, since retrying a POST without an idempotency strategy will create duplicate records.
- How should I test my Dynamics integration without a live production tenant?
- Most teams use contract-level mocking, faking the HTTP layer so your tests assert the OData URLs, filters and payloads your code generates without touching a real tenant. If you want higher confidence, run a smoke suite against a Business Central sandbox using separate credentials and an environment flag. A full sandbox in CI is often gated by tenant provisioning and Azure AD consent, so many projects keep live-tenant tests manual or nightly rather than on every pull request.
- Is this package safe to depend on in production, and what are the alternatives?
- It is a reasonable infrastructure dependency when Dynamics 365 Business Central is your system of record and Laravel is the orchestration layer, but treat it as replaceable: wrap it behind an interface so a fork or swap is cheap. The main risks are vendor coupling to per-tenant customizations, schema drift in the tenant surfacing as runtime errors, and a bus-factor signal that is low for an agency-maintained utility package. Alternatives include calling the OData endpoints directly with Laravel's HTTP client, which gives full control over retries and batching but means you own auth token handling and query construction yourself.
Weaver
How can I help you explore Laravel packages today?