MarketBox is designed to support multiple integration paths, depending on how your business schedules work today and how far you want to go over time.
Some teams start with dispatcher-led workflows. Others rely on third-party calendars. Some want to launch self-booking immediately, while others prefer to evolve gradually. MarketBox supports all of these approaches using the same underlying Smart Clusters scheduling engine and a consistent set of APIs.
Below are the six supported integration patterns. Each one describes:
- When it is the right choice
- What is involved operationally
- Which API endpoints are typically used
- Examples of industries where it is commonly applied
You can start with one pattern and move to another as your business grows.
Integration timelines vary based on data readiness and workflow complexity. MarketBox is designed to plug into existing workflows and systems, not force a full rebuild.
Pattern 1 – Custom Dispatcher Booking Engine
“Build a dispatcher-led booking flow using MarketBox APIs”
When this pattern is a good fit:
Choose this pattern if you do not yet have a dispatcher scheduling system, or if dispatching is currently handled via spreadsheets, email or manual processes.
MarketBox provides the core scheduling and availability intelligence, while you build a dispatcher interface tailored to your operations.
What this involves:
- You build a dispatcher UI or internal tool
- Dispatchers create and manage bookings in your system
- Smart Clusters is used to suggest feasible times and provider assignments
- Your system remains the system of record for bookings
This pattern gives you full control over workflows while avoiding the complexity of building routing and availability logic from scratch.
Estimated dev time: 2-4 weeks
Typical API endpoints:
- Create service
- Create provider
- Create schedule
- Get providers
- Get schedules
- Smart Clusters time slots / availability endpoints
- Create booking or order
- Webhooks for booking updates (optional)
Common industries:
- Utilities and field services
- Home healthcare
- Telecom installation teams
- Any operation with human dispatchers making final decisions
Many teams start with an internal dispatcher booking engine and later extend it into a customer-facing self-booking experience using the same MarketBox APIs.
Pattern 2 – Calendar-Based Booking
“Use a third-party calendar as the system of record”
When this pattern is a good fit:
Choose this pattern if bookings already live in an external calendar system such as Google Calendar or Outlook, and you do not want to introduce a booking database yet.
MarketBox treats calendar events as fixed booking anchors and computes realistic availability around them.
What this involves:
- Existing bookings remain in a third-party calendar
- Your system reads calendar events and passes them to Smart Clusters
- Smart Clusters returns feasible appointment times
- New bookings are written back to the calendar
This is often the fastest path to better scheduling without re-platforming.
Estimated dev time: 2-5 days
Typical API endpoints:
- Get providers
- Get schedules
- Smart Clusters time slots / availability endpoints
- Optional provider and service endpoints for metadata
Common industries:
- Home services
- Mobile healthcare
- Tutoring and lessons
- Small to mid-size mobile service businesses
Pattern 3 – MarketBox Online Booking Engine (OBE)
“Use MarketBox’s built-in booking engine and push bookings via webhooks”
When this pattern is a good fit:
Choose this pattern if you do not have the ability to manage provider schedules or bookings today and want a complete, ready-to-use booking experience with minimal engineering effort.
MarketBox becomes the booking system of record, and your platform integrates via events.
What this involves:
- Services, providers, and schedules live inside MarketBox
- Data is created via the MarketBox admin or public APIs
- Bookings occur in MarketBox’s Online Booking Engine
- Booking and order events are pushed to your system via webhooks
This pattern is ideal for fast launches, pilots, or teams that want to offload booking infrastructure entirely.
Estimated dev time: 1-2 weeks
Typical API endpoints:
- Create service
- Create provider
- Create schedule
- Get services, providers, schedules
- Webhooks for order and booking events
- Optional Smart Clusters endpoints for advanced availability logic
Common industries:
- New marketplaces
- Franchise networks
- Vertical SaaS platforms launching booking for the first time
Pattern 4 – Dispatcher Optimization
“Enhance an existing dispatcher-led workflow with Smart Clusters”
When this pattern is a good fit:
Choose this pattern if you already have a dispatcher system and booking database, but want to improve routing efficiency, reduce gaps, and handle disruptions more effectively.
MarketBox does not replace your dispatcher system. It augments it.
What this involves:
- Dispatchers continue to create and manage bookings in your system
- Smart Clusters is called to suggest better times, assignments or re-routes
- Your system decides which suggestions to accept
- No booking is blocked if Smart Clusters is unavailable
This pattern works especially well in environments with frequent same-day changes.
Estimated dev time: 1-2 weeks
Typical API endpoints:
- Smart Clusters time slots / availability endpoints
- Get providers
- Get schedules
- Optional booking update endpoint
Recommended evolution path:
As booking volume grows, many teams add customer self-booking using MarketBox APIs to reduce dispatcher load and scale operations.
Common industries:
- Utilities
- Logistics-adjacent services
- Home healthcare
- Emergency or high-touch field operations
Pattern 5 – Mobile Enablement
“Turn a fixed-location business into a mobile operation”
When this pattern is a good fit:
Choose this pattern if you already have a booking engine but do not yet support mobile workers or travel-based scheduling.
This pattern focuses on enabling mobility first, then optimizing availability.
What this involves:
- Travel zones are defined using a third-party mapping or polygon tool
- Zone coordinates are passed to MarketBox
- Smart Clusters enforces travel feasibility and clustering
- Existing booking logic remains intact
This pattern unlocks mobile services without a full system rebuild.
Estimated dev time: 2-5 days
Typical API endpoints:
- Update provider travel zones
- Smart Clusters availability endpoints
- Get providers and schedules
Common industries:
- Brick-and-mortar services expanding into home visits
- Fitness and wellness
- Mobile beauty and grooming
- Swim schools and private instruction
Pattern 6 – Booking Engine Optimization
“Enhance an existing booking UI with Smart Clusters”
When this pattern is a good fit:
Choose this pattern if you already have a customer-facing booking engine and want to replace static time slots or buffers with route-aware availability.
MarketBox improves the intelligence behind availability without taking over your booking flow.
What this involves:
- Your booking UI remains unchanged
- Smart Clusters generates feasible appointment options
- Your system applies business rules and fallbacks
- Final booking decisions remain under your control
This pattern delivers immediate customer-visible improvements with low integration risk.
Estimated dev time: 5-10 days (most teams can replace static availability logic in under two weeks without changing their booking UI)
Typical API endpoints:
- Smart Clusters time slots / availability endpoints
- Get providers
- Get schedules
- Create booking or order
Common industries:
- Home services
- Telecom
- Mobile mechanics
- Any self-booking, field-based business
Choosing the right integration strategy
Most teams do not jump directly to the “end state.” Common paths include:
- Pattern 1 → Pattern 4 → Pattern 6
- Pattern 2 → Pattern 4 → Pattern 6
- Pattern 3 → Pattern 6
MarketBox is designed to support these transitions without forcing rewrites.