> For the complete documentation index, see [llms.txt](https://developers-apps-in-toss.toss.im/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developers-apps-in-toss.toss.im/documentation/api-and-sdk-en/integration/server-api.md).

# Using the server API

This guide explains the server communication settings required before using the App-in-Toss API.

### Get a server mTLS certificate

To use the App-in-Toss API, you must **mTLS (mutual Transport Layer Security, mutual transport layer security)** configure a certificate.

mTLS is a method where the client and server verify each other's identity. Standard HTTPS authenticates only the server, but mTLS **allows the partner company's server and the App-in-Toss server to authenticate each other**.

After configuring this certificate, you can ensure the following.

* Encryption of the communication channel
* Only authorized servers can call the API
* Prevention of tampering

Manage the issued certificate as follows.

* Store the certificate and key files securely so they are not leaked.
* Reissue the certificate before it expires.
* If you need a seamless replacement, you can register two or more certificates.

If you have not prepared a certificate yet, first check the mTLS certificate issuance method in the Get server mTLS certificate document.

### Check the communication firewall

If you manage inbound and outbound firewalls on your server, you must allow the IPs and ports below. If you do not, API calls may fail or you may not receive callbacks.

#### Inbound IPs that the merchant must allow

App-in-Toss → Merchant

| IP                | Port |
| ----------------- | ---- |
| 117.52.3.11       | 443  |
| 211.115.96.11     | 443  |
| 106.249.5.11      | 443  |
| 117.52.3.80\~87   | 443  |
| 211.115.96.80\~87 | 443  |
| 106.249.5.80\~87  | 443  |

This is the IP used when App-in-Toss sends requests to the merchant server. For example, it is needed when receiving a subscription status change callback or a data provision consent withdrawal callback at the callback URL registered in the console.

#### Outbound IPs that the merchant must allow

Merchant → App-in-Toss

| Feature                                          | Domain                       | IP                                          | Port |
| ------------------------------------------------ | ---------------------------- | ------------------------------------------- | ---- |
| Simple login, message sending, Toss point payout | apps-in-toss-api.toss.im     | 117.52.3.192, 211.115.96.192, 106.249.5.192 | 443  |
| Simple payment                                   | pay-apps-in-toss-api.toss.im | 117.52.3.195, 211.115.96.195, 106.249.5.195 | 443  |

This setting is required when calling the App-in-Toss API from the merchant server. You must open HTTPS port 443 to communicate properly.

### Allow CORS

To communicate with the server from a mini app, you must add the mini app Origin to the server's allowed CORS Origins.\
The Origins that must be allowed vary depending on the SDK version and the date it is applied.

#### SDK 3.x

{% hint style="info" %}
**SDK 3.x Origin change guide**

Starting with SDK 3.x bundles uploaded after Tuesday, August 25, 2026, service will be provided using the Origin used in SDK 2.x.\
If you communicate with an external server, please add the Origin below to the server's allowed CORS Origins.

* `https://<appName>.apps.tossmini.com` : live service environment

* `https://<appName>.private-apps.tossmini.com` : Console QR test environment
  {% endhint %}

* `https://<appName>.web.tossmini.com` : live service environment

* `https://<appName>.private-web.tossmini.com` : Console QR test environment

#### SDK 1.x \~ 2.x

* `https://<appName>.apps.tossmini.com` : live service environment
* `https://<appName>.private-apps.tossmini.com` : Console QR test environment

### API common specifications

#### Domain information

* <https://apps-in-toss-api.toss.im>
* <https://pay-apps-in-toss-api.toss.im>

#### API common response format

All APIs use a common response structure. `resultType` Check whether it succeeded first using the value.

**Success response**

```json
{
  "resultType": "SUCCESS",
  "success": {
    "sample": "data"
  }
}
```

* `resultType`This `"SUCCESS"`means the request was processed successfully.
* The actual response data is `success` inside the object.
* For each API, `success` the internal structure is different.

**Failure response**

```json
{
  "resultType": "FAIL",
  "error": {
    "errorCode": "INVALID_PARAMETER",
    "reason": "The request failed."
  }
}
```

* `resultType`This `"FAIL"`means the request processing failed.
* `errorCode`is a code that indicates the type of error.
* `reason`contains a human-readable error description.
* If you send an invalid parameter `INVALID_PARAMETER`will raise an error with a code like this.

When handling the response, be sure to `resultType`check it first, then implement separate success and failure logic.

### Request limit policy

The App-in-Toss API limits the number of requests to ensure stable service operation.

#### Default limit

* 3,000 QPM per minute
* QPM stands for Queries Per Minute and means the number of API requests that can be made in one minute.
* Based on a mini app, you can make up to 3,000 requests per minute.

If you exceed this limit, additional requests may be blocked for a certain period of time.

#### When you need a higher QPM

If you need more than the default 3,000 QPM [Channel Talk](https://apps-in-toss.channel.io/workflows/787658)you can request an increase.

When requesting, please provide the following information as well.

* Purpose of use
* Expected traffic volume
* Request volume during peak hours

We adjust the limit after reviewing the business purpose and traffic volume. If heavy traffic is expected, it is best to discuss it in advance before service launch.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://developers-apps-in-toss.toss.im/documentation/api-and-sdk-en/integration/server-api.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
