# Messaging API development guidelines
Follow the development guidelines below when developing a LINE bot that uses the Messaging API.
- Prohibiting mass requests to the LINE Platform
- Prohibiting LINE Platform load tests
- Prohibiting mass transmission to the same user
- Prohibiting requests for non-existent user IDs
- Prohibition of acts that identify the attributes of user ID
- Prohibiting IP address restrictions
- Recommended processing on receipt of unsend event
- Recommending the implementation with anticipation of JSON object structure changes
- Saving logs
The basic rules for LINE bot development are based on what is stated in the terms and policies.
# Prohibiting mass requests to the LINE Platform
Don't send a large number of requests to the LINE Platform for the purpose of load testing or operation testing.
Don't send requests beyond the specified rate limits for any purpose.
If you send requests exceeding the rate limit, you will receive an error message saying, 429 Too Many Requests
.
Even within rate limits, sending the following requests at a high frequency is prohibited.
- Repeatedly creating and deleting audiences even though they are not actually used for sending narrowcast messages
- Repeatedly making requests that aren't for the purpose of using the features provided by the Messaging API
# Prohibiting LINE Platform load tests
There is no service to load test bot servers from the LINE Platform.
For load testing purposes, don't send large numbers of messages via the LINE Platform. Prepare a separate environment for load testing of bot servers.
# Prohibiting mass transmission to the same user
Don't send too many messages to the same user for any purpose.
# Prohibiting requests for non-existent user IDs
When sending a request, don't specify a non-existent user ID.
# Prohibition of acts that identify the attributes of user ID
Don't attempt to identify user attributes for a specific user ID. Also, don't use the Managing Audience API or deliver narrowcast messages for the purpose of identifying user attributes.
# Prohibiting IP address restrictions
On bot servers that receive webhooks, don't restrict access by the IP address of the LINE Platform from which the webhook request is sent.
We don't disclose IP addresses of the LINE Platform. Also, IP addresses are subject to change without notice.
To deny requests from unauthorized sources, use signature validation instead of access control by IP address.
# Recommended processing on receipt of unsend event
When a user unsends a sent message, an unsend event is sent to the bot server.
When the unsend event is received, we recommend that service providers respect the user's intent to unsend a sent message and handle the message appropriately with the utmost care so that the target message can't be seen or used in the future.
For more information, see Processing on receipt of unsend event.
# Recommending the implementation with anticipation of JSON object structure changes
Future additions or changes to the Messaging API functionality may result in changes to the structure of the following JSON objects without notice. Such changes may include adding properties, changing the order of properties, adding or deleting spaces and newlines between data elements, and so on.
- Responses and error responses to API requests
- Webhook Event Objects
You should implement your API requesters and bot servers to successfully receive JSON objects with unconventional structures.
# Saving logs
We recommend saving logs for Messaging API request and webhooks received for a certain period of time so that developers themselves can smoothly investigate the cause and scope of a problem when it occurs.
# Logs for Messaging API request
We recommend saving the following information as a log when making a request to the Messaging API.
- Request ID (
x-line-request-id
) of the Response header - Time of API request
- Request method
- API endpoint
- Status code returned in response by the LINE Platform
More specifically, save it in a log file using the following format.
Request ID (x-line-request-id ) | Time of API request | Request method | API Endpoint | Status code |
---|---|---|---|---|
8e36bade-c5d6-4d00-9e69-72244675a9a1 | Mon, 05 Jul 2021 08:14:35 GMT | POST | https://api.line.me/v2/bot/message/push | 200 |
# Logs for webhooks received
We recommend saving the following information as a log when you receive a webhook from the LINE Platform through the bot server.
- IP address of the webhook sender
- Time webhook was received
- Request method
- Request path
- Status code the bot server returned in response to the received webhook
More specifically, save it in a log file using the following format.
Sender IP address | Time webhook was received | Request method | Request path | Status code |
---|---|---|---|---|
203.0.113.1 | Mon, 05 Jul 2021 08:10:00 GMT | POST | /linebot/webhook | 200 |
Depending on the requirements of the bot, the following information, in addition to the above, can be stored for investigation when problems occur.
- Messaging API request body
- Response body returned by the LINE Platform after the API request
- Signature (
x-line-signature
) of the request header when webhook is sent from the LINE Platform - Webhook event object returned by the LINE Platform
We don't provide logs of Messaging API requests, or logs of webhooks sent from the LINE Platform to the bot server, etc. despite inquiries. Logs should be saved by the LINE bot developers themselves.