Reference · built on requestConnectorHospitality & property systems

Nexudus

Customers, bookings, check-ins, invoices, and contracts from Nexudus workspaces, with booking and note proposals.

Request accessPricing ↗

About

Nexudus runs coworking and flex workspaces: locations, customers (which the API calls coworkers), resources, bookings, check-ins, contracts, tariffs, and invoices. Its REST API lives at https://spaces.nexudus.com/api and is grouped into modules such as Spaces, Billing, System, CRM, Content, and Support. Every resource follows one pattern: search with GET, fetch one by id, create with POST, update with PUT, delete by id, and run commands with POST to /{resource}-run-command. A separate Public API powers the Members Portal, and a Custom Access Control API pushes access changes to a system you host.

Through Fibric, an operator watches bookings against check-ins, unpaid invoices against due dates, and contract changes against door access, then proposes a booking, an internal note, or a record update for you to approve. Each approved change runs once and leaves a receipt.

This is a reference listing. It documents what Fibric would read from Nexudus and what it could propose, based on the vendor's published interfaces. Fibric builds it under a managed deployment when you request it; selecting it here installs nothing.

Inputs

  • Customers through GET /api/spaces/coworkers, filtered by Coworker_Email, Coworker_Active, Coworker_CoworkerType, and from_ and to_ UpdatedOn ranges
  • Bookings through GET /api/spaces/bookings, filtered by Booking_Resource, Booking_Coworker, and FromTime or ToTime ranges, with Tentative and Invoiced flags
  • Check-ins through GET /api/spaces/checkins by Checkin_Business location and Checkin_Source: Manual, DoorAccess, NetworkActivity, Tile, or Sensor
  • Invoices through GET /api/billing/coworkerinvoices, filtered by CoworkerInvoice_Paid and a CoworkerInvoice_DueDate range, with TotalAmount and Paid
  • Contracts, tariffs, products, time passes, and booking credits through the Billing resources CoworkerContracts, Tariffs, Products, CoworkerTimePasses, and CoworkerBookingCredits
  • Resources, resource types, visitors, deliveries, and teams through the Spaces resources Resources, ResourceTypes, Visitors, CoworkerDeliveries, and Teams
  • Access group changes pushed to an HTTPS endpoint you host when day passes, bookings, desk assignments, expirations, deactivations, or check-ins change them

Proposed actions

  • Target capability: propose a booking through POST /api/spaces/bookings with ResourceId, FromTime, and ToTime in UTC
  • Target capability: propose an internal note on a customer through POST /api/spaces/coworkernotes, readable by location staff
  • Target capability: propose a customer record update through PUT on the Coworkers resource

Proposed actions are target capabilities. Every action runs propose-first and needs a validated deployment and the appropriate permissions.

What you can build

  • Release a room nobody arrived for

    Bookings give the schedule. Check-ins with source DoorAccess or Sensor show whether anyone came. When a booking passes with no check-in, the operator proposes releasing the resource and a note on the customer record.

    With Meeting Room Reset

  • Chase an invoice on a set cadence

    coworkerinvoices filtered by Paid false and a due date range lists what is overdue. The operator proposes each reminder step in turn, and you approve before anything is sent.

    With Dunning Cadence

  • Close door access when a contract ends

    A contract expiration changes the customer's access groups, and Nexudus pushes that change to your endpoint. The operator proposes the matching revocation in your door system and records it.

    With Access Offboarding

  • Book a resource from a request

    A member asks for a room or desk. The operator checks bookings for the resource and proposes a POST to bookings with FromTime and ToTime, plus any BookingVisitors named.

    With Amenity Booking

Requirements

  • A Nexudus account on spaces.nexudus.com and a user who is a full unrestricted administrator or holds the role each endpoint names, such as Booking-List
  • For an add-on, an Application Key and Secret Key registered under Settings > Add-ons > Manage add-ons or through POST /api/apps/applications
  • Webhook permission or administrator access to configure webhooks under Settings > Integrations > Webhooks
  • An HTTPS endpoint if Nexudus is to push webhook or access group notifications; it does not send to HTTP
Authentication
An OAuth2 bearer token from POST /api/token with grant_type=password, or Basic Auth on each request; add-ons send their Application Key with an MD5 token derived from the Secret Key.

Limits

  • Listing endpoints return summary records; fields such as InternalNotes and recurrence need a second call per record
  • Bearer tokens expire after 604799 seconds and must be refreshed; Basic Auth transmits credentials on every request
  • The webhooks settings page does not document payload format, retries, or an event list; events are chosen per webhook in the dashboard
  • Booking times are sent in UTC while invoice due dates are in the location's timezone

Access and pricing

Reference listing. Fibric builds the connector under a managed deployment when you request it. Your quote covers the build, capabilities, usage, and support.

Request Nexudus ↗

Questions and answers

How does a server authenticate to the Nexudus REST API?
POST /api/token with grant_type=password returns an access_token and a refresh_token; the access token expires after 604799 seconds and is sent as Authorization: Bearer. Basic Auth with an email and password is also accepted. Add-ons use their Application Key as the username and MD5(token + secretKey) as the password.
Does Nexudus send webhooks?
Yes. Under Settings > Integrations > Webhooks, a user with webhook permission or administrator access picks a Nexudus event and an HTTPS destination. The dashboard shows Last trigger, Last error, and Error count. Separately, the Custom Access Control API posts access group changes to an endpoint you host.
How are lists paged and filtered?
Lists take page (default 1), size (default 25), orderBy, and dir (0 ascending, 1 descending). Filters are named after fields, such as Coworker_Email or Booking_Resource. Ranges use from_ and to_ prefixes in YYYY-MM-DDTHH:mm. Responses carry TotalItems, TotalPages, HasNextPage, and Records.
Ask about Nexudus

Ask about the capabilities and requirements in this listing.

For project-specific requirements, contact Fibric.

This connector listing is developed, published, and supported by Fibric. It describes integration with Nexudus through published interfaces. Third-party names and logos identify the systems an integration connects to; they are the property of their respective owners, who are not affiliated with Fibric and do not sponsor or endorse this listing. Trademark policy