- Charging by the number of API accesses
- Expiration date of authentication
- Handling of date and time
- App configuration that supports stopping the system
- To avoid data loss
- Notes on connection
- Change of items in HRBC
- Requirements definition/Maintenance after starting operation
Charging by the number of API accesses
One Request for accessing the HRBC API including the API for authentication is counted as one access.
The image diagram is as follows:
When the number of monthly accesses to the HRBC API exceeds 150,000 times, 2,000 yen will be added per month for every 10,000 exceeded thereafter.
Consider how to acquire records efficiently to avoid charging.
*The number of records that can be processed by one Request is 200 for both Read and Write.
To process 200 or more records, 200 records must be processed at a time.
The maximum number of requests per minute is 500 for the Write API and 2,000 for the Read API.
For details, please refer to Rate limit for requests per minute, Limit on the number of records
In a past case, authentication or data acquisition failed and the subsequent processing looped, causing several tens of thousands accesses to occur.
When performing implementation, consider error or other possible processing to prevent unexpected API accesses from occurring.
Note that even if there is an unintended increase in the number of API accesses due to crawling or a processing loop, the number of accesses is charged.
Expiration date of authentication
Because the authentication of the HRBC API has its expiration date, the API must be designed to be re-authenticated when it expires.
Note that an access to the API for authentication is also counted as one access, so the method that can minimize the number of authentication times should be considered.
Handling of date and time
The date and time handled by the HRBC API is UTC. Please be careful that JST is not used.
App configuration that supports stopping the system
HRBC and the HRBC API may be stopped due to system maintenance or other reasons.
When developing an app using the HRBC API, it is very important to design such an app considering cases where the system is stopped.
To avoid data loss
The largest number of apps that are developed using the HRBC API are pages for registering job seekers.
The HRBC API is usually operated without stopping except at the time of maintenance; however, the Internet is used for connecting apps and the HRBC API, and thus an unexpected disconnection may occur at any time.
In case of such a failure, it is recommended that before registering data including job seekers using the HRBC API, record them into a log or other recording media so that the data can be registered later.
Notes on connection
The HRBC API is provided as a service called WEB API, and unexpected disconnection may occur.
To avoid such a situation, for critical processing, system configuration should be implemented with measures, such as retry operation, for communication failures.
Risks of doing parallel processing
Please refrain from running parallel processing, as it may cause unintentional errors.
Change of items in HRBC
In HRBC, the [Customize] menu allows users to add or delete items or options as desired.
After developing an app using the API, if the user uses the [Customize] function to delete an item, an error occurs because the item specified by the program no longer exists, possibly causing the app to become inoperable.
It is recommended to define items and options in a setup file or other relevant files as much as possible for later changes.
Also, explain to users in detail about items that must not be changed once an app is created to avoid errors during operation.
Requirements definition/Maintenance after starting operation
Development requirements must include the log management of the Request and Response details, recovery processing for unexpected events, and other necessary processing.
PORTERS does not acquire the log of user’s Request/Response details.
Especially, when there is a contract with an external development company, it is necessary to consider in advance the maintenance contract after the start of operation.
PORTERS is not liable for any problem that occurs because of no implementation of log management or recovery processing, or when no maintenance personnel have been assigned.