Api Bundle Laravel Package

Product Decisions This Supports

• Build vs. buy for the API layer. This is a decision aid, not a dependency you adopt casually. It answers: "Do we hand-roll our API conventions (error envelopes, request validation, auth middleware, versioning, retry policy) or inherit an opinionated set from a vendor that already runs a large data platform?" If Keboola's conventions match your product's needs, this saves weeks of design-by-committee.
• Ecosystem alignment / integration roadmap. The package's real value is interoperability. If your roadmap includes Keboola as a data source, destination, or partner integration, adopting its API semantics (error shapes, auth flow, pagination, job/async patterns) lowers integration friction and support burden later.
• Internal standardization. For teams already inside or adjacent to the Keboola ecosystem, this is a candidate "blessed path" for new services — reducing per-service API drift and review overhead.
• Operational defaults as product input. The 6.3.0 release adds keboola_api.auth.client_options.backoff_max_tries (default 3, capping auth retry backoff at ~7 s for Storage token verification and Manage token exchange). This is the kind of decision a PM usually makes implicitly and badly: how long do we let a flaky identity service hold a user request? It gives you a defensible, configurable default to benchmark against — fail fast on auth, keep controller-facing clients (storage_client_options, autowired ManageApiClientFactory) on their existing behavior. Useful as a reference point even if you never install it.
• Reference architecture, not foundation. Given 0 stars and 0 dependents, the highest-value PM decision it supports is reading it to extract conventions for your own thin internal API kit — borrowing the patterns without taking on the maintenance relationship. 6.3.0 sharpens this: the scoping discipline (fail-fast applies to auth only, not to the controller-facing data path) is a good pattern to copy.
• Framework strategy input. KeboolaApiExtension and the "Bundle" naming confirm this is Symfony, not Laravel. That surfaces a real decision: is our API-layer investment portable across frameworks, or are we tying conventions to one vendor's Symfony idioms?

When to Consider This Package

Adopt (or evaluate seriously) when:

• Your stack is Symfony, not Laravel. 6.3.0 makes this unambiguous — the release is described entirely in terms of DI container IDs and Symfony bundle extension classes. A Laravel team should treat this as pattern reference only.
• You are building services that must talk to or mimic the Keboola platform API.
• You have a named internal owner who can pin a version, read the code, and carry a fork if upstream stalls.
• You value consistency with a single vendor's conventions over community breadth.
• You care specifically about auth resilience tuning — 6.3.0 is a genuine (if small) feature release, not just a version bump, and it shows the upstream is actively hardening real operational behavior.

Look elsewhere when:

• You're a Laravel shop. Terminology mismatch, incompatible service-provider/middleware assumptions, and no Laravel community around it.
• You need ecosystem validation. 0 stars, 0 dependents, and a low composite score mean effectively no third-party production evidence. No Stack Overflow corpus, no plugin ecosystem, no hiring pool familiarity.
• You need long-term vendor independence. A single-vendor package with no dependents is a continuity risk: abandonment, breaking changes, or a license pivot (MIT today, no guarantee of stewardship) all land on you.
• You need a broad API toolkit. Mature alternatives — Laravel's own HTTP/validation stack, API Platform (Symfony), or hand-rolled conventions — carry vastly more support surface.
• You need a stable extension seam. 6.3.0 changes where the auth client factory is registered (KeboolaApiExtension::AUTH_MANAGE_CLIENT_FACTORY_ID instead of keying on ManageApiClientFactory::class). Production callers are unaffected, but any test harness that stubs authentication by hand must be updated. That is a small, contained break — and a useful illustration of the class of change you inherit: container internals behave as semi-public API, and the changelog is the only notice you get.
• Release cadence is a signal. A 6.2 → 6.3 hop with a previously future-dated release indicates the package is still moving quickly and versioned ahead of consumption; treat stability as unproven and pin exact versions.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, MIT-licensed, single-vendor package from Keboola that encodes their API conventions. It is not a strategic dependency and carries no adoption momentum — zero stars, zero dependent projects. The decision it informs is narrow: if we are deliberately building Keboola-adjacent services, it can accelerate that work and reduce integration friction. The new 6.3.0 release is a modest hardening update — a configurable cap on authentication retries so login doesn't hang on transient failures — which is reassuring about upstream maintenance but does not change the strategic picture. It should not become infrastructure for our mainstream product surface. Recommend a time-boxed spike, not a roadmap line item.

To engineering (one paragraph): KeboolaApiExtension confirms this is Symfony, so Laravel teams should read it, not install it. Where it fits — Symfony services integrating with Keboola — it saves boilerplate on request/response conventions, error handling, auth, and now auth retry behavior (keboola_api.auth.client_options.backoff_max_tries, default 3, ~7 s cap, scoped deliberately to auth only and not to controller-facing clients). Budget for ownership: pin the version, read the source, and assume you may fork. 6.3.0 is a live example of why — the auth client factory moved to a new container ID, so any hand-rolled auth stub in your test suite breaks and must be migrated (or adopt AuthenticatorTestTrait and avoid the problem). Do not introduce it into a service that lacks a maintainer who understands it, because there is no community to fall back on. If we're not integrating with Keboola, the better move is to extract the pattern — including the fail-fast auth default — and write twenty lines of our own.

Bottom line for the decision log: evaluate as a reference implementation and integration accelerant, not a platform dependency. 6.3.0 is a small positive maintenance signal and a small negative coupling signal; net position unchanged. Score and adoption evidence still do not support anything stronger.