Typed fixed-route SDK operations
Asset/version reads, upload authorization/finalization, one-version orders, delivery lifecycle, event cursor, masked export metadata and explicit download-link results.
Integrations / INTERACTIVE WORKSHOP
MyProof Client v1.0.0Compose a scoped delivery client
Build sequences across uploads, one-version orders, deliveries, events and masked exports. The actual SDK preserves keys and hides sensitive result values; every HTTP response is a local fixture.
01 / CONFIGURE
Choose a scenario. Change the inputs or build a sequence of commands.
02 / RUN
Execute the installed package against a new fictional example.
03 / INSPECT
Follow the result, actual calls, generated output and integration code.
THE WORKBENCH
Make it your example.
Your server-side changes are temporary. External-service examples use local response fixtures. Start with sample data.
Start with a preset, or change the input and run it.
The behavior is the example.
Your result will show the values, decisions and generated output from the actual package.
Calls used by this scenario. The handbook explains setup, authorizers, storage and error recovery.
The complete response is shown as data. Wide PHP integers are transported as exact decimal strings. Values are never evaluated as PHP or JavaScript.
Run an example to inspect its response.
The last two successful run states stay in this tab’s memory. Run a changed example to compare the actual package results.
What you can exercise here.
Transport/privacy and notifications
Stable key/body retries,409 non-retry, redirects/cookies off, byte ceiling, sensitive default omission and actual raw-body HMAC verification.
Owner domains and application server policy
Domain claim/poll requires a real owner grant and DNS/TLS provider workflow. The SDK includes those methods; this workshop deliberately does not simulate DNS ownership or API server idempotency state.
UNDERSTAND THE BEHAVIOR
A scoped SDK transports data; the host owns trust.
Build real SDK operation sequences for assets, upload sessions, one-version orders, deliveries, events, exports and notifications. All calls use local TEST fixtures; edit delivery rows and compose operation sequences.
Commands invoke the SDK, not a remote workflow
Delivery rows edit paginated responses. Commands exercise fixed routes and actual DTOs, but the fixture server does not emulate durable service state or server idempotency storage. Begin/finalize upload returns metadata; this workshop never uploads visitor bytes.
Retries preserve the request identity
Mutating commands expose an idempotency key. The transient-fault preset records the same key and body hash across retry attempts. Conflicts are not retried; redirects and cookies are disabled and responses have a byte ceiling.
Sensitive results have deliberate projections
Reveal, rotation and download-link operations return sensitive metadata whose normal projections omit private values. Export metadata may describe v2 or collection.v1. The client does not follow the returned upload/download destinations or verify an evidence bundle merely by reading metadata.
Notifications verify exact bytes
The actual NotificationVerifier checks a fixed TEST raw body, HMAC and receiver clock. Altering the bytes or moving outside the permitted window fails. Production credentials, workspace ownership and independently pinned evidence keys remain host requirements.
GO FURTHER
Try the boundary cases.
Page through edited deliveries
Run Three bounded pages and alter reference/status in the delivery-row builder. Replay each deliveries command. Expected: typed rows and next cursors change with the selected page; a larger page budget alone does not issue extra commands.
Follow the version handoff
Run Upload and exact version handoff, then Asset versions and upload revocation. Expected: real SDK upload authorization/finalization, version reads and revocation metadata appear. No file bytes are sent and no remote asset lifecycle is claimed.
Inspect privacy and export metadata
Run Order, delivery and sensitive links and Masked collection metadata. Expected: commands call the real typed APIs while default projections redact private URLs or credentials. Collection part metadata is distinct from retrieving and verifying the ZIP with the evidence package.
Compare transport failure classes
Run POST retry keeps the key and body: expected matching key/body hashes on both attempts. Compare Conflict is not retried, Redirect is not followed and Response byte ceiling. Each should reject at its own transport boundary without following a supplied destination.
Verify notification bytes and install prerequisites
Run Verify a test notification, then changed bytes and stale clock presets. Expected: only the unchanged timely TEST message verifies. For a fresh application, add VCS repositories for both myproof-evidence and myproof-laravel-client before requiring myproof/laravel-client; its evidence dependency must also be discoverable. Copy the complete commands from the package library.
COMPOSE THE RESPONSIBILITIESUseful alone.
Useful alone.
Better when the boundaries fit.
The Laravel client handles scoped service requests and DTOs; myproof/evidence verifies bundle integrity offline against an independent trust pin. Keep credentials, authorization, factual claims and retention in the application. Neither public TEST fixture establishes real receipt or identity.