Public API

A recipe expands into explicit parameters before anything you put in parameters is applied on top. Conventional PET-PEESE and EK are the non-instrumented estimators (the app's WLS model); drop shouldUseInstrumenting: false and you get the MAIVE variant of the same method instead.

curl -s https://api.maive.eu/v1/run-model \
  -H 'Content-Type: application/json' \
  -d '{
    "recipe": "MAIVE",
    "data": [
      {"effect":0.42,"se":0.11,"n_obs":120,"study_id":"Smith2020"},
      {"effect":0.31,"se":0.06,"n_obs":90,"study_id":"Smith2020"},
      {"effect":0.55,"se":0.2,"n_obs":45,"study_id":"Smith2020"},
      {"effect":0.12,"se":0.04,"n_obs":200,"study_id":"Jones2019"},
      {"effect":0.27,"se":0.09,"n_obs":75,"study_id":"Jones2019"},
      {"effect":0.18,"se":0.05,"n_obs":160,"study_id":"Jones2019"}
    ]
  }'

One resolver fills in unset parameters for the browser and the API alike, and some of its defaults depend on the data: study clustering is on when the upload has a study_id column and the standard errors are clustered, and WLS runs with standard weights. Rather than make you re-derive that, every 200 carries resolvedParameters, the complete object the backend ran, and recipe, the named recipe it corresponds to (or null). Report it with the numbers; feed it back to reproduce them.

{
  "effectEstimate": 0.2137,
  "standardError": 0.0412,
  "...": "...",
  "resolvedParameters": {
    "modelType": "WLS",
    "maiveMethod": "PET-PEESE",
    "weight": "standard_weights",
    "standardErrorTreatment": "clustered_cr2",
    "includeStudyDummies": false,
    "includeStudyClustering": true,
    "computeAndersonRubin": false,
    "useLogFirstStage": true,
    "winsorize": 0,
    "shouldUseInstrumenting": false,
    "favorPositive": true
  },
  "recipe": "PET-PEESE"
}

Unknown or misspelled parameter keys and values that conflict with each other are rejected with a 400 naming the problem. The API never silently runs a different analysis than the one you asked for.

{
  "error": {
    "code": "validation_error",
    "message": "Unknown RTMA parameter key: favourPositive. Known keys: modelType, favorPositive, alphaSelect, ciLevel, winsorize, seed."
  }
}

The top level of the body is checked the same way. On /v1/run-model and /v1/run-rtma every parameter, modelType included, goes inside parameters; a modelType sent beside data is a 400 that says where it belongs, not a MAIVE run. Only /v1/runs takes a top-level modelType. Any other key an endpoint does not document at the top level is rejected the same way.

{
  "error": {
    "code": "validation_error",
    "message": "Unexpected top-level key: modelType. modelType is a run parameter and belongs inside `parameters`; this endpoint accepts data, parameters and recipe at the top level."
  }
}

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.

• OpenAPI 3 spec, served by the API host: https://api.maive.eu/openapi.yaml
• llms.txt: https://easymeta.org/llms.txt
• agent.md: https://easymeta.org/agent.md

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.