中文
Documentation menu

Developer Hub/Integration playground

Partner Event API · zero-production-impact

Validate the reference request, then certify your backend

This page runs two zero-impact browser reference tests: Step 1 checks credentials and request format; Step 2 checks the mrt_ test channel. After both pass, the destination engineer must rerun the test from their own backend to certify the actual implementation.

The test API to call

The browser playground and destination backend use the same production endpoint. A test request must include test: true and the mrt_ from the handoff package. Each API response is the result of that specific call, but the browser reference test and destination-backend certification must be evaluated separately. No tenant dashboard login is required.

POST
https://api.meetroas.com/v1/events
Signature and schema only
https://api.meetroas.com/v1/events/validate
Node.js backend test
// Run on the destination backend; inject all three values as environment variables
const crypto = require("node:crypto");

async function main() {
  const endpoint = "https://api.meetroas.com/v1/events";
  const mrClickId = process.env.MEETROAS_TEST_ATTRIBUTION || "";
  if (!/^mrt_[A-Za-z0-9_-]{32}$/.test(mrClickId)) throw new Error("MEETROAS_TEST_ATTRIBUTION must be the mrt_ value from this Key's package");
  const body = JSON.stringify({
    event_id: "partner-smoke-" + Date.now(),
    mr_click_id: mrClickId,
    event: "account_registration",
    occurred_at: new Date().toISOString(),
    test: true
  });
  const timestamp = String(Math.floor(Date.now() / 1000));
  const signature = "v1=" + crypto.createHmac("sha256", process.env.MEETROAS_SECRET)
    .update(timestamp + "." + body).digest("hex");
  const response = await fetch(endpoint, { method: "POST", headers: {
    "content-type": "application/json",
    "x-meetroas-key": process.env.MEETROAS_KEY_ID,
    "x-meetroas-timestamp": timestamp,
    "x-meetroas-signature": signature
  }, body });
  const result = await response.json();
  console.log(response.status, result);
  if (![200, 202].includes(response.status) || result.integration_status !== "passed" || result.delivery_readiness !== "not_applicable") process.exit(1);
}

main().catch((error) => { console.error(error); process.exit(1); });

Certification status

1Credentials & request formatNot run
2Test Click ID & test writeWaiting for Step 1

1. First, validate credentials and request format

Paste the Key ID and Secret from the handoff package, then keep only the events the destination actually supports. The browser sends reference requests to check HMAC, schema, and secure rejection behavior. Step 2 unlocks only after every check passes. This step writes no test or production events.

Values remain only in this tab's memory. The Secret is never written to the URL, local storage, cookies, or result output.

Events your destination actually supports

Uncheck unsupported events. Never invent a business fact only to satisfy MeetROAS.

2. Then, validate the Test Click ID and test write

Opening this page from the package's 15-day Test URL prefills the Test Click ID. This button unlocks after Step 1 passes. It sends test events from this browser to verify mrt_ attribution, persistence, and idempotency; it does not run the destination's own code.

The mrt_ works only with the same Key and belongs to no customer App / Campaign. The test writes only isolated Test Runs, never production events, postbacks, Performance data, or usage.
LockedComplete Step 1 first. The button turns green when it is ready.

Finally: certify your own backend

Passing both Playground steps proves that the handoff package and MeetROAS test channel work. Copy the Node.js example above and send a test: true request from the destination backend with the same Key, Secret, and mrt_. The engineering implementation is complete only after it receives HTTP 200/202, integration_status=passed, and delivery_readiness=not_applicable. No tenant dashboard login is required.

How to read the result

  • Step 1 passed — The credentials sign correctly, and schema, event semantics, and secure rejection behavior match the contract.
  • Step 2 passed — The browser reference request writes Test Runs with the mrt_, and duplicate/conflict semantics are correct. This does not mean the destination code ran.
  • Destination backend passed — The same result must come from the destination's own backend to complete the one-time account integration. Production Campaigns, Goal Bindings, and buyer source setup are separate.

The playground is for integration validation only. Production must read credentials from a server-side secrets manager, persist mrc_ from real traffic, and omit the test field.