Public API

Synchronous endpoints return the result in the same response, which is the simplest thing to call, but they are subject to the edge's roughly 100 second proxy cap. That is comfortable for typical runs (about 15 to 60 seconds including a cold start) and unsuitable for anything larger.

The asynchronous path (POST /v1/runs then poll GET /v1/runs/{jobId} every 2 to 5 seconds) holds no long-lived connection, so it has no failure mode tied to run duration. Use it by default, especially for batch or CI usage. Batch status for several runs at once: GET /v1/runs?ids=a,b,c (up to 100 ids, statuses only).

Send data as an array of row objects. Columns are resolved by canonical key name when present (matched case-insensitively); otherwise the first 3 or 4 keys are read positionally in the order effect, se, n_obs, study_id.

The MAIVE family (/v1/run-model) needs 3 or 4 columns and at least 4 rows. RTMA (/v1/run-rtma) needs 2 columns (effect, se); rows with a missing or non-positive se are silently dropped. These rules mirror the app's own validation page and run server-side, so you get a structured 400 instead of a raw R error.

A minimal valid request is just {"data": [...]}:

{
  "data": [
    {"effect": 0.42, "se": 0.11, "n_obs": 120},
    {"effect": 0.31, "se": 0.06, "n_obs": 90},
    {"effect": 0.55, "se": 0.20, "n_obs": 45},
    {"effect": 0.12, "se": 0.04, "n_obs": 200}
  ]
}

MAIVE, WAIVE, and WLS

RTMA

Plots (funnelPlot, zScorePlot, and their width and height companions) are excluded by default: each is a base64 PNG of roughly 50KB that most callers do not need. Add ?include=plot to any run or poll request to embed them.

Every RTMA response carries a diagnostics object. Check it before using the numbers beside it: mu and tau are modes from an optimisation that runs separately from the sampler, so they can fail on their own while the credible intervals stay sound. A null means the value could not be read off the fit, which is not the same as the fit being healthy.

The response has no standard error for mu on purpose. The se column that phacking reports internally is the Monte Carlo error of the posterior mean, not the posterior standard deviation, and the two differ by more than an order of magnitude on ordinary data. Use muCI for uncertainty.

Every error shares one envelope:

{
  "error": {
    "code": "validation_error",
    "message": "Data must have 3 or 4 columns; found 6."
  }
}

Two guardrails apply: a hard concurrency cap on the compute backend, and per-IP rate limiting at the edge. Both are tuned from observed load, so treat any 429 as "retry with backoff" rather than a hard quota.

• A jobId is an opaque bearer token, not an account-scoped identifier. Anyone holding it can read that run's status and result, so treat it like a share link.
• Runs and their results expire after 48 hours; polling after that returns 404 not_found.
• Synchronous runs are stateless. Asynchronous runs persist the parameters and the result for up to 48 hours; the input dataset itself is not persisted beyond the transient queue message.
• Do not submit confidential or personally identifiable data. There is no data-classification or redaction layer; treat every request the way you would treat a request to any other unauthenticated public web service.

If you use this API in published or reported work, please cite the paper behind the model you ran. RTMA is Mathur's method; the other models are MAIVE's.