Many consumer platforms in Korea and Japan offer no public API. Reservations, delivery, mobility, ticketing and payments each sit behind a different app and a different contract. APIFuse normalises these services behind one gateway. You hold one managed key and call one interface.

How it fits together

Every request goes to the https://api.frism.dev/v1 gateway. The first path segment names the service; the rest names the API you are calling on it. APIFuse keeps the per service credentials, sessions and renegotiations alive for you.

GET /v1/catch-table/restaurants?area=seongsu HTTP/1.1
Host: api.frism.dev
Authorization: Bearer frism_test_k3xample

The service catalog lists which services are open. Each service's API reference is an OpenAPI document generated from fixtures, and the same document is downloadable as openapi.json.

Design principles

• One key: you never create per service accounts. Scopes narrow what the key may do.
• One error model: service outages and gateway errors come back in the same envelope.
• Push first: state changes arrive as webhooks instead of polling.

Next steps

The quickstart walks from issuing a sandbox key to creating the first reservation. Search restaurants is a good first call.