OfficeRnD

OfficeRnD Flex runs coworking and flexible workspace, and the reason to automate against it is that a flex space is four businesses wearing one coat: a community, a property, a subscription business and a helpdesk. This connector covers all four rather than picking one. On the community side, agents read and write members through Get Members, Get Member, Create Member, Update Member, Update Member Status and Update Member Company, read and write companies, and run the sales pipeline through Get Opportunities, Create Opportunity and Update Opportunity. Check-ins are fully covered, and this is a genuine write surface rather than a report: Check In Member and Check Out Member record attendance, and Get Check-Ins reads it back, which is what makes occupancy reporting possible from something other than a door sensor. On the space side, Get Locations, Get Floors, Get Resources and Get Resource are the inventory, and bookings are managed end to end through Get Bookings, Get Booking Occurrences, Get Booking, Create Booking, Update Booking and Cancel Booking.

Memberships and billing are not symmetrical, and the difference matters when you design a flow. Memberships are readable and creatable: Get Memberships reads them, Create Membership signs a member or company up to a plan, and Get Plans reads the plan catalog. There is no update or cancel for a membership here. Billing is read only: Get Invoices, Get Invoice and Get Invoice Documents retrieve invoices with their payment status, due date and documents, and nothing in this connector raises, edits, voids or settles one. So this is the right connector for dunning, revenue reporting and aging analysis, and the wrong place to look for invoice generation. Support is covered through Get Tickets, Create Ticket and Update Ticket, with the caveat that Get Tickets supports no attribute filters at all, accepting only pagination and field selection, so a narrower set has to be filtered inside the flow.

Delete operations are deliberately not exposed. The vendor API can delete members, companies, memberships, bookings, opportunities, visits and fees, and none of those are surfaced here, so a flow cannot destroy an OfficeRnD record. Update Member Status set to Former and Cancel Booking are the closest available and both are reversible in the admin. Payment card endpoints are also deliberately not exposed, keeping cardholder data out of flow variables. Some conventions to build around: all list endpoints use cursor pagination with a page size of 50 that is also the maximum, so a larger limit is capped rather than honored, and each list returns cursorNext and cursorPrev alongside results, which you pass back until cursorNext comes back null. Get Bookings returns one entry per single booking and one per recurring series rather than per occurrence, so individual instances of a recurring series come from Get Booking Occurrences, which requires Series Start and Series End and supports a window of at most one year when pagination is not used. Get Resource Status returns both status and ownStatus for a parent resource containing children, so a private office with one occupied desk reports status: partially_occupied and ownStatus: available, and reading the wrong one produces a confidently wrong occupancy report. Update Booking requires Resource, Start and End on every call per the vendor schema, so all three are sent even when only one is changing.

This connector does ship a trigger. On OfficeRnD Event creates one OfficeRnD webhook per configured trigger through the /webhooks endpoint and deletes it when the trigger is removed, and the payload is the documented envelope with eventId, eventType, objectId, object and the raw data object surfaced, because the keys sitting beside object vary by event type. Creating and deleting webhooks requires the webhook create and delete permissions on the application. Two things are worth knowing. A delete that fails is logged and skipped rather than aborting cleanup, so an orphaned endpoint can survive under Settings, Developer Tools, Webhooks and is worth checking if triggers are removed repeatedly. And deliveries are not signature verified: OfficeRnD stores a secret on each webhook and documents an HMAC SHA-256 format for its partner Connect payloads, but does not publish the header name or the canonical signing string for webhook deliveries, so rather than guess and risk rejecting valid events the connector accepts deliveries on the FlowRunner callback URL without verifying them. Treat the callback URL as a secret, and do not let this trigger be the sole authority for an irreversible action.