Core Concepts

Understanding Rntor’s data model and key concepts

Before building your integration, it’s important to understand how Rntor organizes data. This page covers the key entities and their relationships.

Merchant Hierarchy

Rntor uses a hierarchical structure to organize spaces and resources:

Merchant (Organization)
├── Location (Physical Site)
│   ├── Floor (Optional)
│   │   └── Resource (Bookable Space)
│   └── Resource (Bookable Space)
└── Location
    └── Resource

Merchant

A Merchant represents your organization or company. It’s the top-level entity that owns all locations, customers, and settings.

• Has unique branding and configuration
• Contains all billing and subscription data
• Manages team members and permissions

Location

A Location is a physical site or building. Merchants can have multiple locations.

• Has its own address and contact info
• Contains operating hours and closed days
• Groups resources for management

Resource

A Resource is any bookable space or asset:

Type	Description	Examples
meeting_room	Rooms for meetings	Conference Room A, Boardroom
hot_desk	Flexible desk spaces	Open Workspace Desk #1-50
private_office	Dedicated office spaces	Office Suite 201
event_space	Large event venues	Rooftop Terrace, Main Hall
phone_booth	Small private booths	Phone Pod 1-4
parking	Parking spaces	Spot A1-A20

Customer Model

Rntor distinguishes between individual customers and company accounts:

Company (Optional)
├── Customer (Member)
├── Customer (Member)
└── Customer (Manager)
     └── Can manage company bookings

Customer

A Customer is an individual user who can:

• Make bookings
• Attend events
• Use credits and day passes
• Have subscriptions

Company

A Company groups customers together for:

• Shared billing
• Pooled credits and day passes
• Centralized invoicing
• Dedicated resource assignments

Booking Lifecycle

Bookings move through defined statuses:

Booking Statuses

Status	Description
pending	Awaiting confirmation (if approval required)
confirmed	Approved and scheduled
checked_in	Customer has arrived
completed	Booking time has ended
cancelled	Booking was cancelled
no_show	Customer didn’t arrive

Credits & Day Passes

Rntor supports flexible payment models:

Credits

A virtual currency for booking resources:

• Can be purchased in packages
• Included in subscription plans
• Track spending per customer/company
• Support partial payments

Day Passes

All-access passes for a single day:

• Grant access to specific resource types
• Can be pooled at company level
• Often included in membership plans

Subscriptions & Billing

Recurring memberships with automatic billing:

Billing Cycle	Description
monthly	Billed on the same day each month
quarterly	Billed every 3 months
annually	Billed once per year

Subscriptions can include:

• Access to specific locations
• Monthly credit allocations
• Day pass allocations
• Resource assignments (dedicated desks/offices)

Events

Community events with registration:

• Public Events: Open to all, may require registration
• Private Events: Invite-only for specific customers
• Paid Events: Require payment via money or credits

Rate Limiting

All API requests are subject to rate limits:

Limit	Value	Response
Per minute	60 requests	429 Too Many Requests
Burst	10 requests	Queued for processing

Implement exponential backoff when you receive a 429 response to avoid being temporarily blocked.

IDs and References

All entities use UUIDs as primary identifiers:

{
  "id": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
  "merchant_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
  "location_id": "11111111-2222-3333-4444-555555555555"
}

When building integrations, store these IDs to reference entities in subsequent API calls.