Skip to main content
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.
Auth: merchant JWT.

Request

string
required
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.
string
required
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.
object
required
Test input passed to the function. Should match the input contract for the function type — see Function input fields.
integer
Execution timeout in ms. Clamped only to the global 5000 ms hard cap — an explicit value may exceed the per-type default. Omit to use the per-type default below.

Per-type default timeouts

These apply when timeoutMs is omitted — they are defaults, not caps: Output is capped at 20 KB serialized — larger outputs fail validation. See Functions overview for the full runtime spec.

Example: discount

Response

A successful or failed execution both return 200 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 errors surface as non-200, as a { status, state: "error", message, data } envelope.
boolean
true when the function ran AND its output passed validation.
object
The function’s return value. On a validation failure this is the raw output that failed; null on a hard runtime failure.
integer
Wall-clock execution time inside the WASM worker.
integer
Decoded WASM module size in bytes.
string
Runtime/timeout error message. Present only when success: false.
string
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 with state: "error" and a human message, e.g.: