Now in JapanTabelog reservations are in open beta

Connect Asia's closed services with one API key

Delivery, reservations, payments. Without direct integrations, your agent talks with Asia's major services, connected.

Get a key Read the docs

One dinner reservation, waitlist to payment, handled by an agent

YOU

Put a party of 3 on the waitlist in Hongdae, and take the charge once we're seated.

I'll take two steps: the waitlist first, then the payment.

catch-table.join-waitlist201 Created

APIFuseCatch Tablemanaged key, 176ms

toss-pay.create-payment201 Created

APIFuseToss Pay₩12,000 held, 111ms

You're number 6 in the queue, about 35 minutes. The charge is confirmed at seating.

Every credential is signed and managed behind the managed token.

89 services, 1 key

Why APIFuse

No partnership queue. Closed platforms, open.

Asian commerce runs on services with no public API. APIFuse normalises them into one predictable surface. Same auth, same errors, same shapes.

01 / key
One managed key
APIFuse holds every partner credential. You ship with a single key and never touch a service's own auth.
02 / queue
No partnership queue
Approval structures, business review, minimum volume. Already cleared. You call the endpoint today.
03 / payments
Payments included
Not just reads. Place a delivery order, hold a table, take the charge. The whole transaction is in the API.
04 / agent
Agent native
Everything here is also available as a ready-made tool for agents. Each one declares what it takes and what it returns, so you can hand it to an agent without integration code.

What changes

API integration was built for people. Now agents connect directly.

The gateway absorbs that cost for you. And six things change: connection, format, billing, code, change and errors.

Before and with APIFuse, compared
Aspect	Before	APIFuse
Connection	A signup and key per service	One APIFuse key
Format	A different shape per service	One standard JSON
Billing	Bills scattered across services	One place to check
Code	Rewritten per service	One call pattern reused
Change	Tracked and patched by hand	Absorbed by the gateway
Errors	A different error shape per service	One standard error response

How it works

The grunt work is ours.

Your app speaks APIFuse. APIFuse speaks each platform's private protocol. Scraping, partner SDKs, undocumented mobile endpoints, whatever it takes.

We clean up the schemas
Response shapes, vendor field names and timestamp formats differ by service. We unify them into one normalized contract. Your agent learns one schema, not every service.
- Zero vendor fields leaked
- ISO 8601 and standard error codes
- Services change; the contract doesn't
From vendor raw to the standard schema
{ "wtNo": "71c9ff", "shopSeq": 20481, "sttsCd": "W", "wtOrd": 4, "prsnCnt": 2, "regDtm": "20260816140211", "custNm": "•••", "custTel1": "010-••••-••••" }
{ "id": "wl_71c9ff", "provider": "catchtable", "status": "queued", "position": 4, "party_size": 2, "created_at": "2026-08-16T14:02:11+09:00", "guest": { "ref": "usr_hash_9f21", "phone": "+82-10-••••-••••" } }
The same reservation response in two shapes. Each abbreviated vendor field row is replaced by its standard-name row in the normalized response, and the compact timestamp becomes an ISO 8601 timestamp.
We handle both kinds of auth
Managed tokens, where APIFuse keeps the service account, and Connections, where users link their own. To your agent both are the same call. Signup, login, token renewal and scope management run through one standard flow.
- Managed tokens: credentials stored, signed and renewed for you
- Connection: users link their own account through one standard flow
- Same call syntax either way
Once with a managed key, once with a connection
A Connection is required
Calling Toss Pay needs the user's account connected first.
toss-payauth_mode: linked-account
GET /oauth/callbackPOST /connectionsconnection_id: conn_01J9Connect and continueConnected, resuming the request
POST /v1/catchtable/waitingauth: managed-keyAuthorization: Bearer $APIFUSE_API_KEY
POST /v1/toss-pay/paymentsauth: connection (conn_01J9)Authorization: Bearer $APIFUSE_API_KEY
A Toss Pay connection prompt passes through the OAuth callback, the connection create and the issued connection id to resolve as connected, and a managed-token call sits next to a Connection call carrying the same Authorization header.
We take the hit
Upstream 503s, rate limits and schema changes are absorbed by the gateway. Retries and health checks run around the clock, and status is published in the open.
- Retries that honor Retry-After
- Health checks per service
- A public status page, live
From 503 to 200
Upstream 503
provider_unavailable1.61 s
Automatic retry
Retry-After 1200 msattempt 2/3
200 returned
Health checks 144 a day, every 10 minutes
A timeline where an upstream 503 passes through an automatic retry that honors Retry-After and ends in a 200.