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. The sandbox is rate-limited per calling account; abusive callers (sustained timeouts) are throttled.

Request

wasmBase64
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.
type
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.
input
object
required
Test input passed to the function. Should match the input contract for the function type — see Function input fields.
timeoutMs
integer
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 typeDefault timeoutHard cap
discount500ms500ms
payment_customization500ms500ms
order_validation1000ms1000ms
cart_transform1000ms1000ms
delivery_customization1000ms1000ms
fulfillment_constraints1000ms1000ms
local_pickup_options1500ms1500ms
shipping_rate2000ms2000ms
pickup_point_options2000ms2000ms
Memory cap is 128 MB per execution. 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 / quota errors surface as non-200, as a { status, state: "error", message, data } envelope.
data.success
boolean
true when the function ran AND its output passed validation.
data.output
object
The function’s return value. On a validation failure this is the raw output that failed; null on a hard runtime failure.
data.executionTimeMs
integer
Wall-clock execution time inside the WASM worker.
data.wasmSize
integer
Decoded WASM module size in bytes.
data.error
string
Runtime/timeout error message. Present only when success: false.
data.validationError
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.:
CodemessageWhen
400Unknown function type: <type>type is not one of the nine function types.
400Invalid base64 in wasmBase64: ...wasmBase64 is not valid Base64.
400validation reason from the WASM validatorbytes are not a valid Javy dynamic-mode module.
401Missing or invalid merchant JWT.
429Sandbox rate limit hit. Wait and retry.