Test a Function
Apps
Test a Function
Execute a pre-compiled function in an ephemeral sandbox without installing it.
POST
Test a Function
POST /apps/functions/test runs a pre-compiled WASM module in the same
sandboxed worker the production dispatcher uses — same per-type timeout,
same output validator — but nothing is persisted. No function-run
record, no state change on any installation.
The server does not compile JavaScript. You compile your function
locally with lms function build (Javy dynamic mode), then send the
resulting WASM bytes as Base64. Static-mode modules are rejected.
Use it for:
- Quick iteration in the developer dashboard’s “Try it” editor.
- CI smoke-tests that exercise a compiled function against a known fixture.
- Schema-conformance checks against the type-specific output validator.
Request
Base64-encoded WASM bytes, produced locally via
lms function build
(Javy dynamic mode). Max decoded size is enforced server-side
(~700 KB of Base64). Static-mode modules are rejected.Function type — determines the input shape that will be passed and the
output validator that will check the return value. One of:
discount, shipping_rate, payment_customization,
delivery_customization, order_validation, cart_transform,
fulfillment_constraints, local_pickup_options, pickup_point_options.Test input passed to the function. Should match the input contract for
the function type — see Function input fields.
Execution timeout in ms. Server-clamped to the per-type cap below
(range: 50–5000). Omit to use the per-type default.
Per-type timeouts
| Function type | Default timeout | Hard cap |
|---|---|---|
discount | 500ms | 500ms |
payment_customization | 500ms | 500ms |
order_validation | 1000ms | 1000ms |
cart_transform | 1000ms | 1000ms |
delivery_customization | 1000ms | 1000ms |
fulfillment_constraints | 1000ms | 1000ms |
local_pickup_options | 1500ms | 1500ms |
shipping_rate | 2000ms | 2000ms |
pickup_point_options | 2000ms | 2000ms |
Example: discount
Response
A successful or failed execution both return200 OK — the outcome is
encoded in the data body (success: true/false). The envelope is the
standard { status, state, message, data } shape (state: "success" for a
completed execution). Only auth / bad-request / quota errors surface as
non-200, as a { status, state: "error", message, data } envelope.
true when the function ran AND its output passed validation.The function’s return value. On a validation failure this is the raw output that failed;
null on a hard runtime failure.Wall-clock execution time inside the WASM worker.
Decoded WASM module size in bytes.
Runtime/timeout error message. Present only when
success: false.Output validator error message — present when the function returned but its output shape was wrong.
Example success
Example timeout
Example validation error
Error codes (non-200)
Non-200 responses use the same envelope withstate: "error" and a human
message, e.g.:
| Code | message | When |
|---|---|---|
400 | Unknown function type: <type> | type is not one of the nine function types. |
400 | Invalid base64 in wasmBase64: ... | wasmBase64 is not valid Base64. |
400 | validation reason from the WASM validator | bytes are not a valid Javy dynamic-mode module. |
401 | — | Missing or invalid merchant JWT. |
429 | — | Sandbox rate limit hit. Wait and retry. |