사이드 메뉴
Getting started
Kakao Developers
Login
Communication
Advertisement
- Concepts
- Ad creation: Ad account
- Ad creation: Campaign
- Ad creation: Ad group
- Targeting for ad group
- Custom audience targeting for ad group
- Ad creation: Creative common
- Ad creation: Display creative
- Ad creation: Message creative
- Ad creation: Personalized message creative
- Bizboard landing settings
- Report
- Message management
- Personalized message management
- Message ad management
- Message ad operation
- Ad View management
- Business Form+ management
- Business Form linkage management
- Pixel & SDK linkage management
- Audience management
- Engagement targeting management
- Customer file management
- Friend group management
- Ad account management
- Reference
- Type information
- Error code
Notation guide
This document explains the notation conventions used in the Kakao Developers documentation. Refer to it when reading the parameter and field tables in the REST API reference documentation. For the meaning of the terms used in the documentation, refer to the Glossary.
| Notation | Meaning |
|---|---|
access_token | Code font indicates parameter and field names, values, and code fragments. |
${ACCESS_TOKEN} | An uppercase notation wrapped in a dollar sign and curly braces is a placeholder to be replaced with an actual value. It is mainly used in sample requests. |
yyyy-MM-dd'T'HH:mm:ss | Date and time values are described with a format string. |
(Example: login,message) | The example notation in parentheses shows an actual usage example. |
| Notation | Meaning |
|---|---|
| [App] > [Platform key] | Square brackets indicate the name of a menu, button, or setting item. Square brackets connected with angle brackets indicate a menu path to follow in order. |
Each API and feature description in the developer documentation starts with a basic information table. The basic information table summarizes the specifications and basic information of the API and the prerequisites for using it, and explains what to check before calling the API. The items in the table differ by documentation type.
| Item | Meaning |
|---|---|
| Method, URL | HTTP method and request URL used for an API request. |
| Authorization | Authorization methods available for the request. If the request specifications differ by authorization method, each is described separately. |
| Requirements | Prerequisites for using the API. You can find how to configure each requirement through its link. |
| See also | Related documents that provide necessary reference information. |
| Item | Meaning |
|---|---|
| Reference | Functions and classes of the SDK used to implement the feature. You can check the SDK reference through the links. |
| App setting | Setup tasks required before using the feature, such as installation and initialization. You can find how to complete each task through its link. |
The Requirements and See also items are the same as in the REST API documentation.
The elements of a request are referred to as parameters, and the elements of a response are referred to as fields. Both are described in a table with the Name, Type, and Description columns. Request parameter tables also include the Required column, and response field tables include it only when necessary.
| Notation | Meaning |
|---|---|
O | A parameter that must be passed. In a response table, it means a field that is always included. |
X | A parameter that can be omitted. If a default value exists, it is described in the Description column. |
X* | A parameter that is passed conditionally. The condition is described in a footnote right below the table, and the parameters marked with the same asterisk form a single alternative or combination relationship. If multiple kinds of asterisks are used, the number of asterisks distinguishes which footnote each parameter corresponds to. |
The Description column starts with the definition of a parameter or field, followed by its purpose, conditions, and additional information on subsequent lines. Bold labels distinguish the following information.
| Notation | Meaning |
|---|---|
| Condition | The condition under which a field is conditionally included in the response |
| Important | Information that must be checked before a request, such as a requirement that varies depending on the value of another parameter |
| Available values | The list of values that can be used for the parameter |
| Note | Additional information that is helpful to know |
| Caution | Warnings about parts that are easy to misuse |
The Type column indicates the serialization type of a value or the definition table to refer to.
| Notation | Meaning |
|---|---|
String, Integer, Long, Double, Boolean | Primitive types. Numeric and boolean types are marked as primitive types even if the available values are limited, and the available values are described in the Description column. |
Datetime | A date and time value. The value format is described with a format string in the Description column. |
JSON | An object consisting of key-value pairs. If the items are fixed, they are described in a separate table. |
Multipart File | A file passed as multipart form data. |
String[] | An array type is marked with square brackets after the element type. Arrays of objects and enums with a definition table are marked in the same way (Example: Location[], Enum: DeviceType[]). |
Campaign | A linked type is an object type. Follow the link to see the property table of the object. |
A parameter whose available values are a fixed set of strings is marked as an enum.
| Notation | Meaning |
|---|---|
Enum | An enum parameter. The available values and their meanings are listed in the Description column. |
Enum: Color | An enum with its own definition table. The link in the Type column points to the definition of the type itself, and all available values and their meanings are in the linked definition table. If values are also listed in the Description column, only the listed values can be set or returned in that API. |
The title of an enum definition table is written in the Enum: Name format, with additional information in parentheses if needed (Example: Enum: Status (Campaign)). A definition table consists of the Value and Description columns, and the Value column is not written in code font. If the meaning of each value is a single specific attribute, the attribute name is used as the column title instead of Description (Example: Hexadecimal color code in Enum: Color).
| Notation | Meaning |
|---|---|
| (Default) | Indicates that the value in a value list is applied by default when omitted. |
(Default: BLUE) | Indicates the default value applied when the parameter is omitted. |
| (Maximum: 50 characters) | Indicates the maximum length or size that a value cannot exceed. |
(Minimum: 1, Maximum: 45, Default: 1) | Indicates the allowed range and the default value together. |
Fixed to PUBLIC | Indicates that the value is fixed and no other value can be used. In a response table, it means a field that always returns the same value. |
| A value from 1 to 50 | A numeric range is written as A to B, and both ends are inclusive. |
| (Unit: seconds) | Indicates the unit used by a numeric parameter. |
| 640x640 pixels | Image dimensions are written in the width x height format, followed by the unit. |
The parameter tables in the Android, iOS, JavaScript, and Flutter SDK documentation mark types with the actual types of each programming language (Example: List<String> in Kotlin, [String] in Swift). Enums and objects are also marked with the class types defined in the SDK, and the detailed specifications are available in each SDK reference.
The other notation conventions apply the same as in the REST API documentation.