Api Client Laravel Package

Product Decisions This Supports

• Make-or-break platform bet: hosting provider selection. Adopting this SDK is effectively a decision to standardize on mittwald as our infrastructure provider (or at least as a first-class provider). It is a vendor-maintained client for one company's API — not an abstraction over many. This should be an explicit architectural decision, not an incidental one made by whichever engineer writes the first provisioning script.
• Feature: automated provisioning / self-service infrastructure. If any roadmap item involves spinning up hosting projects, installing apps, attaching domains, issuing certificates, or managing backups on mittwald, this package removes the "write and maintain our own HTTP client" workstream. Typical candidates: signup-to-live onboarding flows, customer-facing control panels, plan upgrades with resource changes, environment creation for trials or demos.
• Build vs. buy. The client itself is a "buy" (free, MIT, vendor-maintained) — the real buy decision is the hosting contract behind it. Building a parallel client only makes sense if we need a provider-agnostic interface, in which case this package becomes one adapter behind that interface rather than a direct dependency in feature code.
• Operational and back-office tooling. Usage reconciliation, billing/plan auditing, bulk domain or certificate management, scheduled backup verification, and lifecycle automation (suspend/restore/teardown) are all natural, lower-risk first use cases — internal-only, no customer-facing blast radius.
• Roadmap risk register item: vendor lock-in and exit cost. Adopting this package raises the cost of ever leaving mittwald, and raises the cost of supporting a second provider. That trade-off should be recorded and revisited, not assumed away.
• Ecosystem signal: 3 stars, 0 dependents. Treat this as an early-adopter SDK. That does not disqualify it (it is official and MIT-licensed), but it means we will not have a Stack Overflow corpus, third-party examples, or battle-tested community patterns to lean on. Budget for our own reference implementation and internal docs.

When to Consider This Package

Consider adoption when:

• We already run workloads on mittwald, or a signed/planned commercial commitment makes mittwald a multi-quarter choice. An SDK for a provider we have not chosen is a solution looking for a problem.
• The required mStudio surfaces (projects, apps, domains, certificates, backups) map to a concrete feature or ops workflow we have scoped. Adopt per-workflow, not "just in case."
• The team is PHP/Laravel-native. Note this is a framework-agnostic API client, not a Laravel package — expect to register it in the service container and wrap it yourself. Integration cost is hours, not days, but it is not composer require and done.
• We want typed request/response models and generated coverage instead of hand-rolled Guzzle calls against a public REST API — this is the strongest argument for the package over DIY.
• We accept vendor-shaped code in our domain layer and are willing to keep it behind a thin internal interface (recommended: wrap it, do not call it from controllers or jobs directly).

Look elsewhere when:

• Multi-provider or multi-cloud flexibility is a stated product requirement, or the business may re-evaluate hosting within the planning horizon. Use an internal provisioning port and treat this SDK as one implementation.
• The stack is not PHP, or the team's Laravel usage is incidental and mostly front-end.
• The workflow is better served by infrastructure-as-code (Terraform, Pulumi, Ansible) than by imperative API calls from application runtime. Provisioning from a request cycle is a category error for anything long-running or retry-sensitive — pair it with a queue and an outbox, or push it into CI/IaC.
• The needed API endpoints are not yet covered by the client (or are marked experimental upstream), or we require support/SLA guarantees that an MIT-licensed SDK with no dependents cannot provide.
• We need a mature ecosystem: no community, no examples, no third-party integration patterns. If the team has no appetite to be the de facto early adopter, wait or budget for spike work first.

How to Pitch It (Stakeholders)

For executives (one paragraph): mittwald publishes a free, MIT-licensed PHP SDK for their hosting platform's management API. Using it lets us automate provisioning and infrastructure management — creating projects, installing applications, attaching domains, managing backups — without building and maintaining a client ourselves, saving an estimated few weeks of engineering plus ongoing maintenance. The decision it actually encodes is a platform commitment to mittwald. The SDK is official but early-stage (minimal public adoption), so the risk is ecosystem immaturity, not licensing or cost.

For engineering leadership:

• Cost: no license fee; effort is roughly a day of integration plus tests, versus multiple weeks for a bespoke client with typed models and error handling.
• Quality posture: vendor-maintained and versioned, which is better than a homegrown client that rots when the API changes. Pin the version, subscribe to upstream releases, and add contract tests around the calls we depend on.
• Architecture requirement: wrap it in a narrow internal interface (e.g., a HostingProvisioner contract) and bind the mittwald-backed implementation in the container. This keeps the option to swap providers or add a second one without touching feature code, and it makes the lock-in cost visible and bounded.
• Operational guardrails: never call long-running provisioning synchronously in a request; use queued jobs with idempotency keys, retries, and reconciliation. Treat the API as an unreliable external dependency — timeouts, rate limits, and partial failures are expected.
• Decision requested: approval to treat mittwald as a first-class provider for the specific workflows listed, and acceptance of the early-adopter risk. If leadership is not ready to commit to mittwald beyond this quarter, do not adopt the SDK directly — scope the internal interface first and defer implementation.