> 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 server API

This guide covers the server communication settings required before using the Apps in Toss API.

### Get a server mTLS certificate

To use the Apps in Toss API, you must **mTLS (mutual Transport Layer Security, bidirectional transport layer security)** set up a certificate.

mTLS is a method where the client and server verify each other's identities. Standard HTTPS only authenticates the server, but mTLS **the partner company's server and the Apps in Toss server authenticate each other**.

Setting up this certificate ensures the following:

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

Manage issued certificates as follows.

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

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

### Check communication firewalls

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 IP the merchant must allow

Apps 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 Apps in Toss sends requests to the merchant server. For example, it is needed when receiving subscription status change callbacks or data provision consent withdrawal callbacks through the callback URL registered in the console.

#### Outbound IP the merchant must allow

merchant → Apps in Toss

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

These are the settings required when calling the Apps 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 need to add the mini app Origin to the server's allowed CORS Origin.\
The Origin you need to allow depends on the SDK version and the effective date.

#### SDK 3.x

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

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

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

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

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

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

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

* `https://<appName>.apps.tossmini.com` : production environment
* `https://<appName>.private-apps.tossmini.com` : console QR test environment

### Common API specifications

#### Domain information

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

#### Common API response format

All APIs use a common response structure. `resultType` First check success or failure by the value.

**Success response**

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

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

**Failure response**

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

* `resultType`If it is `"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 invalid parameters, `INVALID_PARAMETER`an error is returned with a code such as

When processing responses, be sure to `resultType`check it first, then implement separate success and failure logic.

### Request limit policy

The Apps 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 per minute.
* For mini apps, 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 a higher QPM is needed

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

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 large traffic is expected, it is best to discuss it in advance before the 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.
