Awork Php Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy for work-management integrations. If your roadmap includes syncing projects, tasks, time tracking, or team workload data into a Laravel app, this package is the "buy/adopt" side of that decision — it replaces hand-rolling an HTTP client, auth handling, and DTO mapping against the awork REST API.
• Roadmap sizing for awork-dependent features. Adoption cost is low (Composer install, illuminate/http is the only framework surface visible in the changelog), so features like "push project status from awork into our dashboard" or "mirror time entries into billing" can be scoped as thin integration work rather than a platform project.
• Vendor lock-in assessment. Choosing an SDK ties your integration surface to awork's API shape. This is the artifact to evaluate when deciding whether awork stays as the system of record for delivery work or becomes a swappable downstream tool.
• Internal tooling and back-office automation. The most likely near-term use case is one-directional syncs and reporting pulls (PMO dashboards, capacity reports, invoicing reconciliation) rather than customer-facing, latency-sensitive paths.
• Not supported by this release: v0.5.0 contains only Dependabot dependency bumps (illuminate/http 12.33 → 12.36, plus two minor/patch group updates). There are no new features, no deprecations, and no breaking changes. Treat it as a maintenance signal, not a capability signal.

When to Consider This Package

Adopt when:

• awork is already (or is about to become) a system of record for projects, tasks, or time tracking, and you need Laravel-side read/write access.
• Your team is on a current Laravel release — the illuminate/http 12.x line in this release implies Laravel 12-era framework expectations. Confirm the constraint in composer.json before committing.
• You want the integration to be a thin, testable layer rather than bespoke Guzzle calls scattered across jobs and controllers.
• You can tolerate pre-1.0 churn: this is a v0.x package, so SemVer permits breaking changes in minor releases. Even v0.5.0 was shipped as a minor bump, and it happened to be non-breaking — that is not a guarantee for v0.6.

Look elsewhere when:

• You need a stable, contractually-supported integration surface. A solo-maintained timkley/* SDK with no visible release cadence beyond dependency bumps is a maintenance risk you should price in (consider vendoring or wrapping behind your own interface).
• You are not on Laravel — the illuminate/http dependency pulls framework components; a plain PSR-18 client or the vendor's own SDK would be lighter.
• Your needs are read-only and narrow (e.g. one endpoint). A direct HTTP call plus a cached response may be cheaper than a dependency you must keep patched.
• You need guaranteed API coverage parity with awork's public API. The changelog gives no evidence of coverage breadth; verify endpoint support against your actual use cases before committing.

How to Pitch It (Stakeholders)

To executives: awork is where delivery work is tracked; today we have no programmatic link to it, so reporting and billing reconciliation are manual. This package is a small, low-cost adapter that lets our Laravel platform read from and write to awork without building and maintaining a custom client. Cost is one dependency and a thin service class; the risk is that the package is pre-1.0 and maintained by a single author, so we should wrap it behind our own interface and budget a small amount of ongoing upkeep.

To engineering: add timkley/awork-php-sdk as an adapter behind a first-party interface (e.g. AworkGateway), bind it in the container, and keep all SDK types out of domain code. That isolates us from pre-1.0 breakage and from abandonment. Note the illuminate/http 12.x constraint when pinning; the v0.5.0 release is dependency hygiene only — no migration work required, and no reason to accelerate adoption on the strength of this release. Evaluate endpoint coverage against our top three use cases before scheduling the integration.