Kbc Manage Api Php Client Laravel Package

Technical Evaluation

Architecture fit. keboola/kbc-manage-api-php-client is a framework-agnostic PHP SDK wrapping Keboola Connection's Manage API — the control-plane surface used to provision and administer projects, stacks, master tokens, and related resources. It is not a Laravel package: there is no service provider, no config file, no facade, and no published Laravel integration layer. In a Laravel codebase it would sit as a Composer dependency inside a thin adapter of your own (a service provider binding a configured client singleton, plus a config file for the Manage API endpoint and master token). That is a small amount of glue, but it is glue you own and must test. Fit is therefore good for teams that already treat Keboola as an infrastructure dependency and need programmatic provisioning; poor as an ad-hoc convenience library, since every call is a privileged control-plane operation.

Integration feasibility. Expected mechanics are conventional: Guzzle/PSR-18 transport, typed request/response objects, exceptions on non-2xx. That is easy to install and easy to call from a Laravel job or artisan command. The real feasibility question is not code integration but credential and tenancy design: a Manage API master token is a high-privilege secret that can create and destroy projects. Storing it in the app's env and using it from a web request path would be a design defect. Feasible, but only behind a deliberate boundary — queue workers or a dedicated provisioning service, never the user-facing request cycle.

Technical risk. Three risks dominate. First, opaque change history: v10.4.0's release notes contain no described changes, only a compare link between v10.3.0 and v10.4.0. Semver implies a non-breaking minor, and the 10.x line suggests the project has already absorbed major-version churn, but "no notes" means we cannot distinguish a bugfix from a behavioural change in error handling or payload shape. Second, blast radius: a client bug in a control-plane SDK can misprovision or delete tenant infrastructure, not merely render a bad page. Third, lock-in and lifecycle: the library is Keboola-maintained, so its release cadence and PHP-version support follow the vendor's roadmap, not ours.

Key questions. (1) What actually changed in v10.4.0 — is there a diff review or changelog entry beyond the compare link? (2) Which PHP versions and which Guzzle/PSR-18 majors does 10.4.0 support, and does that match our runtime? (3) Is the Manage API versioned independently of the client, and what is the supported-version window? (4) Who holds the master token, and is there an audit trail for provisioning calls? (5) Is there a sandbox or non-production Keboola stack for integration testing?

Integration Approach

Stack fit. Clean as a library, not as a Laravel citizen. Assume Laravel 10/11 on PHP 8.2+; the client should install cleanly alongside an existing Guzzle. The adapter is roughly: a KeboolaServiceProvider, a config/keboola.php holding base URL plus token reference, and a bound pre-configured client. Keep the raw SDK out of controllers and models — expose intent-named methods (provisionProject, rotateMasterToken) so the vendor types do not leak into domain code.

Migration path. There is no prior assessment, so v10.4.0 is the baseline rather than an upgrade. Treat adoption as greenfield with a spike: install, authenticate against a sandbox stack, and exercise the two or three calls you actually need before committing to the dependency. If a parallel internal tool already provisions projects by hand or by script, plan to run the SDK path read-only alongside it first — list and describe operations only — before enabling any mutating call.

Compatibility. Because 10.4.0's contents are undocumented, pin exactly (10.4.0, not ^10.4) until you have reviewed the diff. Verify PHP constraint, Guzzle major, and whether the package depends on psr/http-client interfaces that could conflict with your HTTP client of choice. Confirm the Laravel version matrix empirically via a throwaway install rather than assumption.

Sequencing. (1) Diff review of v10.3.0→v10.4.0 and a decision on pinning strategy. (2) Sandbox spike with read-only calls. (3) Build the service provider, config, and secret handling. (4) Add mutating operations behind a queue job with idempotency keys and structured logging. (5) Contract tests against the sandbox in CI. (6) Only then wire into any product-facing workflow.

Operational Impact

Maintenance. Low code surface, ongoing attention. The SDK itself needs little care, but the adapter and pin must be revisited on each vendor release — and since notes for 10.4.0 were effectively empty, budget for reading diffs manually or for subscribing to the repository's releases and issue tracker. Expect breaking changes at each major (the 10.x number implies a history of them); schedule an annual dependency-review slot.

Support. Vendor-supported library, community/enterprise support via Keboola rather than a Laravel ecosystem maintainer. Escalation for "the SDK sent a malformed payload" lands with Keboola; escalation for "our provisioning job broke" lands with us. Document that split before go-live so the on-call rota is not surprised.

Scaling. The client is thin and stateless; scaling is bound by the Manage API's rate limits and by the number of provisioning operations, not by the library. Provisioning is inherently low-volume and slow (project creation is not instant), so model it as long-running queued work with generous timeouts rather than synchronous calls. Watch for retry storms — a naive retry loop against a control plane is the most likely way to trip rate limits and create duplicate resources.

Failure modes. Partial provisioning (project created, token or user assignment failed) leaving orphaned infrastructure; retries without idempotency producing duplicates; token expiry or rotation silently breaking scheduled jobs; transient 5xx from the Manage API surfacing as raw exceptions in a user path; version drift where a pinned client no longer matches a deprecated API endpoint. Each maps to a concrete control: compensation/cleanup jobs, idempotency keys, token-expiry alerting, circuit breaking, and an upgrade deadline.

Ramp-up. A competent Laravel engineer unfamiliar with Keboola needs roughly two to three days to be productive: half a day on the client API surface, a day on Keboola's project/stack/token model (the actual learning curve — the SDK is the easy part), and a day building the adapter and sandbox tests. Add a half-day of documentation on the master-token threat model, since that is the operational detail most likely to be gotten wrong by the next person to touch the integration.