REST API, hooks and driver interfaces
How to extend Schedopia without forking it. The REST API, capabilities and rate limits, lifecycle hooks and filters, the three driver interfaces, and the database layout.
Design principle
Every booking, whatever its origin, passes through one validated path. The booking form, the admin, the REST API and any extension all call the same core, which checks availability and writes inside a transaction. An extension therefore cannot create a booking the core would reject, and the double-booking guard holds everywhere.
REST API
The full API lives under:
/wp-json/schedopia/v1/Everything the admin can do is available through it: services, categories, add-ons, staff, availability, bookings, customers, payments, venues, halls, seats and events.
- Schema-driven validation: every route declares its arguments and types, so invalid requests are rejected with a clear error before they reach the core.
- Granular capabilities: admin routes are protected per area, so you can grant a role access to bookings without giving it access to settings.
- Rate limiting on the public routes used by the booking form.
The route list with argument schemas is discoverable from the API’s index (/wp-json/schedopia/v1/) in the standard WordPress REST format.
Hooks and filters
Schedopia fires documented lifecycle hooks around bookings, payments and notifications, and offers filters to adjust behaviour without patching files. The hook reference is maintained alongside the plugin source, which you can browse on WordPress.org’s Trac.
Driver interfaces
Three interfaces define how new capabilities plug in:
| Interface | Purpose |
|---|---|
BookingSource |
Bring bookings in from another channel, for example a kiosk or a partner site. |
NotificationChannel |
Send notifications by another method, such as SMS or a chat tool. |
PaymentMethod |
Add a way to take or record payment, including online gateways. |
Implement the interface in your own plugin and register it. The core calls your implementation at the right moment and still owns validation and persistence.
Database
Schedopia uses custom relational tables prefixed wp_schedopia_ (with your site’s prefix) rather than custom post types. Bookings, services, staff, customers, payments, venues, seats and events each have their own table with proper keys, which keeps queries fast and reporting straightforward.
Note: Query the tables for reporting if you like, but write through the API or the core so the validation path and the activity log stay complete.
Local development
- PHP 8.1 or later and WordPress 6.5 or later.
- Enable
WP_DEBUGto surface deprecation notices. - Watch the Activity Log while testing: it records every state change and is the quickest way to confirm what your extension did.