Butler Service Laravel Package

Product Decisions This Supports

• Build vs. buy / integration strategy: Confirms glesys/butler-service is a live, maintained dependency. A patch release with a scoped feature is a positive maintenance signal for teams deciding whether to build a bespoke client against the Butler API or lean on this package.
• Data fidelity for large numeric values: The new Long scalar for 64-bit integers removes a real correctness gap. Any product surface that round-trips large integers — resource IDs, millisecond/precision timestamps, monetary amounts in minor units, snowflake-style identifiers — can now be represented without silent truncation or lossy float coercion.
• Feature unlock, not feature debt: This is additive. No deprecations, no removals, no config changes. It is a safe patch bump to schedule in a normal maintenance window rather than a planned migration.
• Roadmap input: If the roadmap includes exposing Butler-backed data to JavaScript clients or other consumers whose numeric types are 64-bit-safe but not arbitrary-precision, this release is a prerequisite for those stories. Without it, those features would need per-field workarounds (stringified IDs, custom serializers) that are more expensive to maintain.
• Risk posture: Low. A single new scalar type, one contributor, one PR. Nothing in the changelog suggests schema reshaping or behavioural changes to existing types — existing consumers should be unaffected.

Note: this assessment is based on the v0.31.1 changelog and repository metadata only; downstream impact should be validated against your actual call sites that handle integer fields.

When to Consider This Package

Consider adopting when:

• You are integrating with the Glesys Butler API and want typed requests/responses rather than hand-rolled HTTP calls.
• Your data model contains identifiers or quantities that exceed 32-bit range or that must survive a JSON round-trip intact — the Long scalar is now a first-class option for those fields.
• You are standardised on Laravel/PHP and value a dependency that follows the framework's conventions over a language-agnostic SDK.
• You can tolerate a pre-1.0 version line: at 0.31.x the public API is still stabilising, so pin to a minor version and read changelogs on every bump, including patches.

Look elsewhere when:

• You are not on the Glesys platform — this package is purpose-built for a single vendor surface and carries no value outside it.
• You need multi-language clients; a PHP-only package will fragment your integration layer if services are polyglot.
• You require long-term API stability guarantees or an LTS support window. Pre-1.0 semver offers none; a 0.32.0 could legitimately break you.
• Your runtime is 32-bit PHP. A 64-bit scalar is of limited use where PHP_INT_SIZE is 4 — verify your deployment targets before relying on it.
• You only need a handful of read-only endpoints; a thin HTTP client may be cheaper to own than a full dependency.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk patch release to a dependency we use for Glesys Butler integration. It adds support for 64-bit integers, which means large IDs and precise numeric values can now pass through our system without being silently corrupted. There are no breaking changes, no migration effort, and no new operational burden. It is a routine upgrade we can absorb in a normal sprint.

For engineering: v0.31.1 introduces a Long scalar type for 64-bit integers. This is the correct primitive for IDs, epoch-millisecond timestamps, and minor-unit monetary values that currently risk truncation at JSON or client boundaries. Action items: (1) bump the dependency and confirm the new scalar is registered and serialises correctly; (2) audit existing integer-bearing fields to see which should migrate to Long; (3) add boundary tests around PHP_INT_MAX and negative values, particularly where data crosses into JavaScript or other 64-bit-unsafe consumers; (4) keep the version pinned, since the package is still pre-1.0 and minor bumps are not guaranteed non-breaking.