Customer Requests

API request: date filter on /text_messages and /calls endpoints
Hi LeadSimple team, I'm John Ely, owner-operator at Rely Real Estate Co. We've integrated your REST API into our analytics layer to surface "last contact" data on tenant communications — it's been a real value-add for our delinquency workflow. I'd like to ask whether you have plans (or an undocumented option) to support server-side date filtering on two endpoints: GET /rest/text_messages GET /rest/calls What we'd like to be able to do: Filter records by created_at so we can pull only recent communications (e.g., last 90 days) rather than the full account history. Something like: GET /rest/text_messages?created_at_gte=2026-02-12&per_page=100 A working sort=-created_at parameter would also solve this — we could paginate newest-first and stop once we hit our cutoff. Why it matters for us: We currently have ~26,000 text messages and ~6,000 calls in our account. To pull a 90-day window of either, we have to paginate every record (260+ pages of texts) and filter client-side, since the only supported parameters appear to be page and per_page. That puts heavy load on your rate limits — we routinely hit the records budget and pause through 65-second retry windows. Our refresh job runs once nightly at 2 AM MT (mapped to the 3x rate scaling window per your docs), and even then a single text_messages pull takes 15–20 minutes. What we've tried: sort=-created_at — confirmed silently ignored in testing created_at_gte, created_at_from, since, from, filter[created_at_gte] — all 504 timeouts or no effect Reducing lookback window — only partial mitigation since we still paginate the older records first My ask: Three options, ranked by what would help us most: Server-side date filter on /text_messages and /calls (created_at_gte or similar). Biggest win. Working sort parameter so we can paginate newest-first and stop at our cutoff. If neither is on the roadmap: point me toward any existing pattern I've missed — maybe an undocumented filter, a different endpoint that returns the same data with filter support, or a webhook that pushes new communications so we can avoid the full re-pull. Even just a "no, not planned, here's our suggested workaround" response would be helpful — it lets us decide whether to invest in further optimization or move to a webhook-based ingestion model. Happy to provide our account ID or API key ID if that helps your engineering team trace specific request patterns. Thanks for the consideration — John Ely Owner, Rely Real Estate Co. john@relyrealestateco.com
Load More