Monitoring

Overview

Monitoring is scoped per app and keyed off your verified credentials. Every authenticated /open/v1/* request is recorded as a success or a failure, then rolled up into the metrics below. Pull them on demand from GET /open/v1/usage to build a dashboard, a health check, or an alert.

Key metrics

• Total API Calls — the total number of requests your app has made over the selected window (summary.totalCalls).
• Success Rate — the share of those calls that returned a non-error response (HTTP status below 400) (summary.successRate), colour-coded against the health thresholds below.
• Last 6h Calls — a short-window view of recent activity, used to spot a sudden spike or a stall in traffic.

Health thresholds

Success rate is banded with the same colour coding used on the platform dashboard:

App status: Live vs Active

Your app moves through a lifecycle that determines which environment it can reach:

• Active — approved for the Sandbox environment, where you test against simulated data.
• Live — promoted to Production. Only live apps count toward platform production traffic and appear in the Live Apps total.

Success rate and call volume are tracked for both, but production incidents matter most once your app is live.

Query your usage

GET https://sandbox.open.mallplus.ph/open/v1/usage returns your call statistics and live quota, scoped to the calling app:

{
  "success": true,
  "data": {
    "summary": { "successRate": 99.6, "successCalls": 14760, "failCalls": 69, "totalCalls": 14829 },
    "endpoints": [
      { "endpoint": "GET /open/v1/orders", "totalCalls": 8021, "successCalls": 8001, "failCalls": 20, "successRate": 99.75 }
    ],
    "quota": {
      "window": "per_minute",
      "limit": 600,
      "used": 53,
      "remaining": 547,
      "resetAt": 1716277260
    }
  }
}

Pass ?from= and ?to= (ISO-8601, clamped to 90 days) to scope the statistics, or ?endpoint= to drill into a single path. The response requires only your standard app credentials — no extra scope. For the quota block and rate-limit headers, see Rate Limits.

Usage over time

Add ?granularity=daily or ?granularity=hourly to GET /open/v1/usage to get a series block — a bucketed time-series of your call counts, so you can pinpoint the exact hour a rate-limit spike or error surge started without raising a support ticket.

• Hourly — one bucket per hour over the last 7 days (up to 168 buckets).
• Daily — one bucket per day over the last 90 days.

Omit granularity and the response is unchanged — the summary/endpoints/quota shape above with no series. Combine with ?from= and ?to= to narrow the window.

{
  "series": {
    "granularity": "hourly",
    "from": "2026-05-19T00:00:00.000Z",
    "to": "2026-05-26T00:00:00.000Z",
    "buckets": [
      { "ts": "2026-05-26T14:00:00.000Z", "totalCalls": 128, "successCalls": 126, "failCalls": 2 }
    ]
  }
}

• Every ts is UTC and bucket boundaries are UTC-aligned — they do not shift to your local timezone.
• Buckets with zero calls are returned as 0 rather than omitted, so the series has no gaps.
• An invalid granularity (anything other than daily or hourly) returns 400 VALIDATION_ERROR.

Building alerts

• Poll /open/v1/usage on a schedule and alert when summary.successRate drops below 90%.
• Break down failures with ?endpoint= to find which path is regressing rather than watching only the aggregate.
• Watch quota.remaining and throttle before you are rate limited — a rising failure rate is often the first sign of over-calling.