Atlato Developer
DocsUse CasesCommunitySupport
DocsUse CasesCommunitySupport
Facebook
Linkedin
Instagram
  1. Guides
  • Overview
    • Developer Platform
  • Getting Started
    • Register Account
    • Manage Apps
    • Manage a Company
    • App Access
    • Store App Access
    • Mode
  • App Store
    • Authentication
    • Access Rights
    • Event Log
    • Company Settings
    • Manage Account
  • Device Integration
    • Design
    • Installation
    • Device List
  • Device API
    • Protocols
    • New Integration
    • Data Output
    • Device Input Names
  • Deployment
    • Custom Client App
  • API Request
    • REST API
    • Request Structure
    • Metadata
    • Pagination
    • Errors
    • Troubleshooting
  • Support
    • Developer Request Types
  • Guides
    • Best practices
    • Timezones
    • Libraries
    • Key Concepts
    • Terms of Use
    • Rate limits
  • Feedback Center
    • Feedback
    • Community
    • FAQ
  • Api Integration
    • Use token in your app
    • Event Logging API
    • Meta Data API
    • Lastest Device Data API
    • Past Device Data API
    • Devices API
    • Country City Currency API
  • App Integration APIs
    • Meta Data
    • Meta Data API
    • Lastest Device Data API
    • Past Device Data API
    • Event Logging API
    • Devices API
    • Country City Currency API
  • Developer Platform
    • Access
    • User
    • Device
    • Manage Account
    • Company
  1. Guides

Best practices

Avoid Polling#

To avoid exceeding the API rate limit, it is advisable to subscribe to webhook events instead of repeatedly polling the API for data. This approach ensures that your integration remains within the API usage constraints. By subscribing to webhook events, you will receive real-time updates whenever the specified events occur, eliminating the need for constant API requests.

Make authenticated requests#

Authenticated requests benefit from a higher primary rate limit compared to unauthenticated ones. To prevent surpassing the rate limit, it is recommended to make authenticated requests.

Avoid concurrent requests#

To prevent exceeding secondary rate limits, it is advisable to make requests one after the other rather than simultaneously. Implementing a queue system for handling requests can help achieve this.

Pause between mutative requests#

When making a significant number of POST, PATCH, PUT, or DELETE requests, it is recommended to wait at least one second between each request. This delay will help you avoid triggering secondary rate limits.

Handle rate limit errors appropriately#

When you encounter a rate limit error, it is essential to temporarily halt making requests according to the following guidelines:
1.
If the retry-after response header is present, do not retry your request until the specified number of seconds has elapsed.
2.
If the x-ratelimit-remaining header shows 0, avoid making another request until the time specified by the x-ratelimit-reset header, which is in UTC epoch seconds.
3.
If neither of these headers is present, wait for at least one minute before retrying.
INFO
Refer Troubleshooting for resolve rate limit issues.
If your requests continue to fail due to secondary rate limits, implement an exponential backoff strategy, where you increase the wait time between retries gradually, and stop retrying after a certain number of attempts.
Persisting in making requests while rate-limited may lead to your integration being banned. For more details, please refer to the rate limit documentation.

Do not ignore errors#

Repeatedly ignoring 4xx and 5xx error codes is not advisable. Instead, ensure that you are correctly interacting with the API. For instance, if an endpoint requires a string but you are passing a numeric value, a validation error will occur. Similarly, attempting to access an unauthorized or nonexistent endpoint will result in a 4xx error.
Continually disregarding validation errors can lead to the suspension of your app for abuse. Therefore, it is crucial to address these errors promptly and adjust your requests to meet the API's requirements.
Modified at 2024-07-18 11:42:10
Previous
Developer Request Types
Next
Timezones
Built with