Reference implementation

The org-simulator is a small, self-contained Node application that plays a complete organisation — both sides of every contract in these docs — with a dashboard UI. It is a mock LMS backend with its own isolated JSON store; it never touches your systems.

:::note Available on request The org-simulator is currently distributed by the integration team. Ask your integration contact or write to [email protected] and we will send it to you together with its README. There is no public download URL. :::

What it demonstrates (copy the code freely)

Contract	What the simulator shows
Request signing + every API call	A signed client: METHOD\nPATH\nTIMESTAMP\nRAW_BODY, path without query and percent-encoded, unix-ms timestamp, lowercase-hex HMAC-SHA256 — used for health, push (dry-run and commit), GET /cases/{loan}, recall, poll, delivery log, replay, webhook test-ping and echo-signature
A correct webhook receiver	Signature verification over the raw request bytes with your secret, eventId dedupe (a replayed delivery is logged as duplicate — deduped, not re-applied), per-case sequence handling with gap detection, tolerance for the ping envelope's null fields, and a loan book that updates itself purely from webhook payloads using the absolute totalCollected / outstandingAfter values
The pull API contract	A cursor-paged GET endpoint returning { rows, nextCursor, hasMore } in the same row contract as push
The Mode B mint-link contract	A mint endpoint that checks the registered Authorization header value, answers { success:true, link:{ linkId, url } }, plus a pay page for the minted link — paying on it calls POST /cases/{loan}/payments/confirm back at Fieldproof automatically, with the payment id as reference
The poll API	Cursor-following poll of GET /cases/updates, persisting nextCursor after each page
Recovery drills	Replay a delivery, fire a webhook test-ping, run echo-signature, recall a loan — each with the request and response shown in the log panels

Everything the simulator sends and receives is visible in two log panels, so a failed signature or a rejected row is immediately diagnosable — that is what makes it useful as a side-by-side reference while you build your own integration.

Running it against the sandbox

1. Configure it with your sandbox base URL (https://alpha-gig.fluxusforge.in), your organisation code, your test apiKeyId and the one-time secret — the README that ships with it lists the exact environment variables — and start it. It stores its data in a local JSON file per organisation; delete the file (or use the reset button) to start over.
2. For Fieldproof to reach it (webhooks, pull, mint), it must be reachable on a public HTTPS URL — expose it with any HTTPS tunnel and set that public base URL in its configuration so minted pay-page links point at it too.
3. Give your integration contact the resulting callback URL (and pull / mint URLs if you use those modes) to register in your sandbox configuration (onboarding).

Then walk the sandbox test matrix from its dashboard: health check → seed mock loans → push (dry-run, then commit) → watch case.received arrive signed → ask the Fieldproof team to assign, visit and (Mode A) verify a proof → see payment.collected / case.closed update the loan book → run the recovery drills (poll, replay, test-ping, echo-signature, recall).

:::tip Treat it as a reference, not a dependency The simulator is a teaching aid and a test rig — copy its signing, verification and dedupe logic into your own codebase rather than deploying it. Your production integration should have exactly the property its dashboard shows: your loan book is driven entirely by the events we send. :::