OwnerRez's API is protected by a per-IP rate limit of 300 requests every 5 minutes. Exceeding the rate limit will cause all requests to return a 429 HTTP code and the following JSON body:
{
"code": 429,
"error": "Rate limit exceeded."
}
This value is continually evaluated, and requests will be blocked once this limit is reached. The IP address is automatically unblocked after it falls below the limit.
- API Integration Best Practices For Avoiding Rate Limit Issues
- Queue Webhooks and Process Asynchronously
- Maintain a Local Data Mapping
API Integration Best Practices For Avoiding Rate Limit Issues
Our goal is to ensure all partners build reliable, performant integrations without encountering unnecessary API rate limits. For most integrations, which serve a few dozen users, the default rate limit is sufficient when following core best practices.
Queue Webhooks and Process Asynchronously
A high volume of API calls is often caused by inline processing when a webhook is received. Inline processing means your application immediately tries to query our API or perform heavy logic before returning a success response to the webhook.
We strongly recommend the following pattern:
- Immediate Response: When you first receive a webhook, store the payload immediately (e.g., in a dedicated queue or database table) and return a 200 OK response to OwnerRez within 2 seconds. This signals success and prevents us from marking your endpoint as failing.
- Background Processing: Use a separate background worker process to handle the stored webhook data.
- Implement Retries: With a background queue, you can easily implement retry logic for processing errors (like rate limiting, temporary system outages, etc.).
This process protects your webhooks from becoming disabled due to slow processing and manages your API usage efficiently.
Maintain a Local Data Mapping
Querying the API for every single webhook is inefficient and is the most common cause of rate limiting. Your application should function as the source of truth for its own data mapping, not as a constantly refreshing mirror of the OwnerRez API.
- Initial Sync: Perform a bulk data query (in a background process with retry logic) only once when a user first connects, or initiates a manual resynchronization as needed to restore consistency from an outage. Pull all necessary entity IDs and relevant, stable data.
- Real-time Sync: After the initial sync, utilize webhooks to maintain the synchronization of your local data. Since we include the entire entity payload in the webhook notification, you should be able to process the change without needing to immediately call the OwnerRez API for additional details.
By maintaining a mapping of OwnerRez data on your end and relying on the webhook payload for real-time updates, you drastically reduce the number of necessary API calls and remain well within the standard rate limit.