Checkybot Laravel Laravel Package

Product Decisions This Supports

• Multi-step integration test coverage without bespoke glue code. ApiCheck::source(url, path) lets a check harvest a value from one API response (e.g., an auth token, a created resource ID, an order reference) and inject it into the URL and expected assertion values of subsequent checks via the {source} placeholder. This is the difference between "we can test that endpoints respond" and "we can test that our core user journeys actually work end to end."
• Make-or-buy on test orchestration. Chained checks cover a capability teams otherwise build in-house (custom CI scripts, Postman/Newman collections, seeded fixture generators). If your roadmap includes synthetic monitoring or post-deploy smoke tests for stateful flows, this package now competes with those self-built options rather than only with simple uptime pingers.
• Roadmap signal for "real workflow" monitoring. Prior to v0.2.3 the package addressed stateless request/assert checks. Chained sources move it toward journey-level verification — relevant if you plan to sell or rely on end-to-end SLA reporting rather than per-endpoint availability.
• Scoping caveats that affect estimates. The feature is server-gated: {source} substitution happens on a Checkybot server that supports sources. The client-side API is only half of the dependency, so any roadmap item depending on chained checks must budget for server upgrade/availability, not just a package bump.
• Sequential dependency in test design. Chained checks imply ordering and shared state between checks — a meaningfully different test-authoring model. Product and QA need to agree on failure semantics (what happens to downstream checks when the source step fails?) before this becomes a load-bearing part of release gating.

When to Consider This Package

Consider adopting when:

• You are on Laravel/PHP and want endpoint checks defined in code alongside the application, reviewed in the same PRs, rather than maintained in an external tool.
• Your critical paths are stateful: authenticated flows, create-then-read-then-delete sequences, or anything requiring an ID or token produced by an earlier call. v0.2.3 is specifically the release that unlocks this class of checks.
• You control (or can upgrade) the Checkybot server, and can confirm version compatibility with source support before committing.
• You want post-deploy smoke tests triggered from CI with minimal new infrastructure.

Look elsewhere or defer when:

• You cannot run a source-capable Checkybot server. Without it, ApiCheck::source() is unusable regardless of the client API — a hard blocker, not a soft preference.
• You need non-HTTP verification (message queues, scheduled jobs, browser rendering); this package is scoped to API checks.
• Your tests are intentionally independent and order-free by policy — chained sources introduce coupling that may conflict with your test-design standards.
• You require a stable, versioned public API. 0.x versioning with server-version coupling means breaking changes are plausible; treat integration as a tracked dependency, not a fire-and-forget install.

How to Pitch It (Stakeholders)

For executives: v0.2.3 adds chained API checks — the ability to take a value from one API response (an auth token, a newly created record's ID) and feed it into the next check. Practically, this upgrades our automated testing from "is each endpoint up?" to "does the actual customer journey still work after deploy?" That reduces the class of regression that only surfaces in production. Cost is low — a package update plus a server version we need to confirm — but it is a server-coupled feature, so it is not a drop-in client-side change.

For engineering: ApiCheck::source(url, path) registers a source request; the server substitutes {source} in the dependent check's URL and in assertion expected values with the value resolved at path from the source response. The substitution is server-side, so the client API alone is insufficient — verify the target Checkybot server supports sources before wiring this into CI. Two things to settle in design review: (1) failure propagation when a source step fails, and (2) whether chained checks should be treated as ordered suites with shared state, since that changes how we isolate and re-run failures. Pin and track the dependency; 0.x plus server coupling means upgrade review is required, not optional.