Laravel Productive Laravel Package

Product Decisions This Supports

• Build vs. buy for Productive integration: This package is a strong “buy/borrow” accelerator over building a Productive API client from scratch. It covers 668 OpenAPI operations across 139 resources plus 3 hidden single-create endpoints, with generated typed resources, models, inputs, enums, and contract tests. For a Laravel team, that can remove weeks to months of integration work.
• Roadmap enablement: Supports features that depend on Productive as a system of record: project and time tracking dashboards, budget and utilization reporting, invoice and people syncs, client portals, internal ops tooling, and cross-system automations. The broad endpoint coverage means most Productive-backed roadmap items are technically reachable without waiting for custom client work.
• Feature scoping by risk: Read-heavy features are the best initial bet because reads are verified against recorded live responses. Write-heavy features—updates, deletes, actions—need a validation budget: only 14 creates have been sent to the live API, so PMs should plan a spike or pilot before committing write-dependent roadmap items.
• Platform and tenancy decisions: Multi-organization and per-call token support, Octane safety, cache-backed per-token throttling, and retry policy fit multi-tenant Laravel products. The testing fake, request assertions, and factories make CI-friendly integration work more practical, reducing regression risk.
• Maintenance strategy: The weekly spec-drift workflow that opens a PR when the generated SDK changes is a meaningful lifecycle advantage. PMs should still decide whether the team pins versions, tracks upstream changes, or contributes fixes, especially while the package is pre-1.0.
• Use-case fit: Best for Laravel products that need broad Productive coverage and are comfortable adopting an early-stage, generated SDK. Narrow integrations—only a few endpoints—may still be cheaper with a thin custom client.

When to Consider This Package

• Consider it when:

  • You are building a Laravel/PHP product that integrates deeply with Productive.
  • You need broad endpoint coverage rather than a handful of API calls.
  • You want typed models, inputs, enums, JSON:API handling, filters, sorting, includes, report grouping, and cursor pagination out of the box.
  • You need multi-organization and multiple-token support, Octane safety, throttling, and retry behavior.
  • You want a testing fake, request assertions, and factories to support TDD/CI.
  • Your first release is read-heavy or reporting-focused, where the package’s live-verified reads provide more confidence.
  • Your team can tolerate a v0.1.0 dependency and validate write paths before relying on them.

• Evaluate carefully when:

  • Write-heavy workflows—updates, deletes, actions—are core to the first release. The package’s own notes say writes are mostly spec- and fake-verified, not live-verified.
  • You need webhook-driven, near-real-time behavior on day one. There is no webhook receiver yet.
  • You require a stable 1.0+ SDK with a vendor-backed SLA.
  • You are not on Laravel/PHP or do not want a generated SDK in your dependency graph.
  • You only need a small subset of endpoints; a thin custom client may be simpler.
  • You cannot accept dependency on upstream OpenAPI corrections and generated-code updates.

How to Pitch It (Stakeholders)

• Executives: This package substantially reduces the cost and schedule risk of integrating Productive into our Laravel product. It provides a typed, tested client for the full API, handles multi-organization access and rate limits, and includes automated spec-drift maintenance. It is v0.1.0, so the right pitch is a read-heavy pilot first; write-heavy features need a validation budget, and webhooks are a later addition.
• Engineering: It gives us typed resources, models, inputs, enums, JSON:API documents and relationships, query builders with filters/sorting/includes/report grouping, pagination with next-link loop protection, retry handling, per-token throttling, and Octane-safe multi-org support. The Productive::fake() testing layer records wire requests and seeds responses, with assertions and factories. Artisan productive:ping, publishable config, and maintenance commands reduce setup and upkeep.
• Product/operations: We can ship Productive-backed dashboards, syncs, portals, and automations faster, with less custom API plumbing. Keep write-dependent features behind a short validation spike until live write coverage improves; plan webhook ingestion as separate work. Overall, this is a credible accelerator for the right scope, not yet a fully proven write platform.