Time Slot Real-Time Behavior by Integration

Overview

This article outlines how each integration retrieves and caches appointment availability (time slots), including the level of real-time accuracy and any caching layers involved.

Most integrations operate on a per-request (pull) model, often combined with short-lived caching. Additionally, all integrations are wrapped by a centralized slot caching layer, which impacts effective freshness.

---

Integration Breakdown

Calendly

Near Real-Time — Short-TTL Caching

• Uses GET /user_busy_times API endpoint
• Memory cache: 10 seconds
• Redis cache: 3 minutes (weekly data)
• OAuth tokens refreshed hourly via scheduled job
• Pause blocks stored in Redis with 7-day TTL

---

Acculynx

~5 Minutes Stale

• Direct API calls per request
• Busy times cached at 5 minutes
• Calendar metadata cached at 2 hours

---

Lead Perfection

Per-Request / Real-Time

• Uses Forward Look API on every request
• No significant caching layer
• Effectively real-time per call

---

Market Sharp

Per-Request / Real-Time

• Direct API calls per request
• No documented caching for availability data

---

Job Nimbus

Per-Request / ~1 Minute

• API calls per request
• Task list cached at 1 minute
• Falls back to synthetic schedule when needed

---

Service Titan

Per-Request / Real-Time

• Direct calls to Capacity API
• No caching for availability data
• SMS-related data cached at 5 minutes

---

Builder Prime

~10 Minutes Stale

• Per-request availability lookups
• Employee/resource data cached at 10 minutes

---

ImproveIt 360 (Salesforce)

Per-Request / Real-Time (Corrected)

ImproveIt 360 retrieves actual appointment availability in real time. The previously noted 4-hour cache does not affect slot data.

Slot Retrieval Behavior:

• All slot data is generated per request via SOQL queries
• No caching is applied to actual availability results

Two Slot Generation Paths:

1. Schedule Override Mode

• Triggered when override settings match configuration
• Generates synthetic availability from business hours
• Queries Salesforce appointments and subtracts booked times
• Fully real-time

2. Direct Time Block Mode

• Queries i360__Time_Block__c records directly via SOQL
• Fully real-time

Cached Component (UI Only):

• hasTimeBlocks() check cached at 4 hours
• Used only to determine whether the scheduling UI should be displayed
• Does not impact slot accuracy or freshness

Key Point:
Slot availability is always real-time per request. The 4-hour cache only affects whether the scheduling interface is shown, not the data within it.

---

Lightning (Salesforce)

Per-Request / Real-Time (Corrected)

Lightning follows the same model as ImproveIt 360.

• Slot data retrieved via per-request SOQL queries
• No caching applied to availability data
• 4-hour cache applies only to a “has time slots” existence check
• UI visibility may be cached, but slot data remains real-time

---

Centralized Slot Cache Layer

All integrations are wrapped by the appointment-page-api-slots caching layer:

• Memory cache: 1 minute
• Redis cache: 3–5 minutes
• Controlled via useCache flag per request

Impact:
Even integrations that are real-time at the API level may return slightly stale data if served from cache.

---

Summary Table

Integration	Method	Cache TTL	Real-Time Level
Lead Perfection	Per-request API	None	✅ Real-time per call
Market Sharp	Per-request API	None	✅ Real-time per call
Service Titan	Per-request API	None	✅ Real-time per call
Calendly	Per-request API	10s mem / 3m Redis	~Near real-time
Job Nimbus	Per-request API	1m task list	~1 minute stale
Acculynx	Per-request API	5m busy times	~5 minutes stale
Builder Prime	Per-request API	10m employee data	~10 minutes stale
ImproveIt 360	SOQL per request	4h (UI check only)	✅ Real-time slots
Lightning	SOQL per request	4h (UI check only)	✅ Real-time slots

---

Key Takeaway

• Most integrations are real-time per request, but not push-based.
• The centralized cache (1–5 minutes) is the dominant factor in effective data freshness.
• As a result, practical staleness across integrations is typically 1–5 minutes, even when upstream systems are real-time.