Origami Api Sdk Laravel Package

Product Decisions This Supports

• Build vs. buy (here: build vs. reuse). This is a first-party PHP SDK for the central Origami API, already consumed by origami_admin_v2. The real decision isn't "should we adopt a vendor library" — it's "does every Origami service keep hand-rolling Guzzle calls, or do we standardize on the sanctioned client?" Standardizing is the cheaper path for any second or third consumer.
• Platform consolidation / API surface strategy. The structure (Data / Guest / Oauth repositories, param bags, DTOs) makes the SDK a de facto contract for the API. Every time a new endpoint is added here, you're deciding that endpoint is stable enough to expose. That's a roadmap artifact, not just code.
• Time-to-market for new features. Param bags + DTOs mean a new admin screen that reads sellers/products is mostly wiring, not HTTP plumbing and response parsing. This directly shortens estimates for Origami-ecosystem feature work.
• Breaking-change detection as a product safeguard. DTOs validate API responses and throw typed exceptions on mismatch. That converts "silent wrong data in the UI" into "loud build/test failure" — a reliability lever you can point to when justifying the SDK's maintenance cost.
• Ecosystem extensibility. If Origami ever exposes a partner/merchant-facing API, Guest and Oauth repositories are the natural on-ramp. Worth an explicit decision now: is this an internal tool or the seed of a public SDK?
• AI-assisted contribution capacity. The repo ships versioned conventions (skills/sdk-conventions) covering param bags, DTOs, enums, exceptions, helpers and tests. That's an unusually strong signal for onboarding velocity and for letting agents generate conformant code — a real input to staffing and delivery planning.

When to Consider This Package

Adopt it when:

• You're building a PHP/Laravel service in the Origami ecosystem that needs authenticated, guest, or OAuth calls to the central Origami API.
• You want typed responses and typed errors rather than arrays and ad-hoc catch blocks — i.e., you care about consistent error states in the UI.
• You already depend on the Origami API for more than a couple of endpoints; the layering (repositories → client repositories → DTOs) pays for itself at that scale.
• You can accept the coding conventions wholesale. The skill mandates class layout, Pint style, spread-merge, param-bag naming, and "document new patterns in the same PR." Teams that fight this will resent it.
• Someone owns it. A shared SDK with no named maintainer becomes a bottleneck the moment the API changes.

Look elsewhere when:

• Your stack isn't PHP/Laravel — the helpers explicitly adapt Laravel, and the value proposition collapses outside it.
• You need one or two endpoints, once. Writing a thin client is less work than learning param bags, DTO validation rules, and exception families.
• You need streaming, webhooks, async queues, or heavy pagination ergonomics — nothing in the documented conventions suggests these are covered; verify before assuming.
• You need generated clients from an OpenAPI spec for many languages. A hand-built PHP SDK is the wrong shape for that goal.
• The public health signals are all you have. Zero stars, zero listed dependents, and an unusual release date mean you must confirm the internal consumer list and release cadence with the owning team before betting a roadmap on it.

How to Pitch It (Stakeholders)

For executives (one paragraph): The Origami API SDK is our own typed PHP client for the central Origami API, already used by origami_admin_v2. Recommending it as the standard for Origami-ecosystem services is a cost-avoidance play: it removes duplicated HTTP and response-parsing code from every new service, makes API contract changes fail loudly in tests instead of quietly in production, and gives us a single place to version and evolve the integration. The investment is one owned maintainer and adherence to documented conventions; the return is shorter integration timelines and fewer data-integrity bugs. Caveat to state plainly: it is internal tooling with no external adoption signals, so the business case rests on our own consumer count, not on community traction.

For engineering: It's MIT-licensed, Laravel-flavored, and opinionated on purpose — repositories in, DTOs out, param bags for requests, a typed exception hierarchy, enums, and Laravel-adapting helpers. The conventions are versioned alongside the code and cover tests, so review is objective and new contributors (human or agent) have a single source of truth. Two asks before we commit: (1) name a maintainer and a release/deprecation policy, since API changes in the sibling origami_api repo will flow straight through; (2) confirm coverage for anything beyond request/response work — auth refresh, retries, rate limits, pagination — because that's usually where a "thin SDK" quietly becomes a framework. If we adopt, we adopt the conventions too; a partially-conformant fork gives us the maintenance cost without the consistency benefit.