RimAPI: A Multi-Tenant Mock API Response Engine

Frontend teams wait on backends. QA waits on frontend. The bottleneck is almost never the API contract, it is having a live endpoint that behaves like the real one. RimAPI is the tool I built so that the contract is the endpoint. Define a route, attach responses, hand the URL to whoever is waiting.

Routes and responses

A route is a method plus a path pattern. A route has one or more responses. Each response has a status, headers, a body, and an optional condition. When a request hits the route, RimAPI evaluates responses in order and returns the first whose condition matches. If none match, it returns the default response.

{
  "method": "GET",
  "path": "/users/:id",
  "responses": [
    {
      "status": 200,
      "condition": "params.id === '1'",
      "body": { "id": 1, "name": "Mengseang" }
    },
    {
      "status": 404,
      "condition": "params.id === '999'",
      "body": { "error": "USER_NOT_FOUND" }
    },
    {
      "status": 200,
      "default": true,
      "body": { "id": 0, "name": "Mock user" }
    }
  ]
}

Conditional responses are the killer feature

A single mock endpoint that always returns the same body is useful for a day. A mock endpoint that returns success for one ID, not found for another, and a server error for a third is useful for an entire sprint. Conditions let QA exercise every client code path without asking anyone to deploy anything.

Multi-tenant and RBAC

Organizations contain projects. Projects contain routes. Roles scope what a user can do: viewer, editor, admin. Public mock URLs are read-only and rate-limited, so a frontend dev can hit them from a deployed app without credentials, while the team manages routes behind auth.

The contract is the endpoint. Once the mock behaves like the real API, nobody is waiting on anybody.