> ## Documentation Index
> Fetch the complete documentation index at: https://www.spacebring.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# Changelog
> Discover the latest changes to the Spacebring API and webhooks.
Subscribe to our [newsletter](https://www.spacebring.com/partnership#subscribe) to be notified about developer platform updates.
A user whose profile the authorized user may not see is now left out of transactions instead of being returned with `null` fields, the
same as in bookings. The user object (`customer.user`, `userCreatedBy`, `userOwner`, a refund's or a booking's user) and every reference
to them (`userRefOwner`, `userRefCreator`, `customerRefCreatedBy`, `membershipRef`, `membershipRefCreator`) are omitted. Admins of the
location and requests authenticated with an API key still get every user.
Transactions retrieved with an OAuth2 access token respect the privacy settings of the users they embed. When the authorized user is not
an admin of the location, another user's `name`, `surname`, `photoUrl`, `about`, `email`, and `phoneNumber` are `null` unless that user
shares their profile, email, or phone number with them. Requests authenticated with an API key are unchanged. This applies to [retrieve
credit transactions](/docs/developer/api/transactions/retrieve-credit-transactions), [retrieve a credit
transaction](/docs/developer/api/transactions/retrieve-a-credit-transaction), [retrieve day pass
transactions](/docs/developer/api/transactions/retrieve-day-pass-transactions), [retrieve a day pass
transaction](/docs/developer/api/transactions/retrieve-a-day-pass-transaction), [retrieve money
transactions](/docs/developer/api/transactions/retrieve-money-transactions), [retrieve a money
transaction](/docs/developer/api/transactions/retrieve-a-money-transaction), [retrieve scheduled credits
transactions](/docs/developer/api/transactions/retrieve-scheduled-credits-transactions), and [retrieve scheduled day pass
transactions](/docs/developer/api/transactions/retrieve-scheduled-day-pass-transactions).
[Retrieve visits](/docs/developer/api/visitors/retrieve-visits) filters by visitor with `userRefVisitor`, the id of the user who visits, as
returned in each visit's `userRefVisitor`.
A booking paid by invoice carries `payments[].method.invoice.invoiceRef`, the invoice its invoice item was added to. It is not set while
the item is pending. This applies to [get a booking](/docs/developer/api/resources/get-a-booking), [retrieve
bookings](/docs/developer/api/resources/retrieve-bookings), [create a booking](/docs/developer/api/resources/create-a-booking), and [update a
booking](/docs/developer/api/resources/update-a-booking).
[List invoice items](/docs/developer/api/billing/list-invoice-items) accepts `invoiceRef` to list the items of one invoice, in place of
`customerRef` or `locationRef` or together with them. They page and sort like the rest of the list, and the other filters still apply.
[List invoice items](/docs/developer/api/billing/list-invoice-items) lists pending invoice items with `pending=true`, for one customer with
`customerRef` or for a whole location with `locationRef`. [List upcoming invoice
items](/docs/developer/api/billing/list-upcoming-invoice-items) is deprecated: use list invoice items with `pending=true` and `customerRef`
instead. It keeps working for existing integrations. Listing the items of one invoice (`GET /billing/invoices/v1/{invoiceId}/items`) is no
longer in the API reference and keeps working too. In list invoice items, `createDate[gte]` and `createDate[lte]` filter by when the item
was created, while `status`, `issueDate[gte]`, and `issueDate[lte]` filter by the invoice the item is on.
The OpenAPI spec lists the OAuth2 authorization, token, and refresh URLs on `https://oauth2.spacebring.com/api/oauth2/`, the same URLs the
[authentication](/docs/developer/api/authentication#oauth2) page documents. The `https://api.spacebring.com/oauth2/` URLs it listed before
reach the same endpoints and keep working, so existing integrations need no change.
Location `media` follows the order administrators arrange the photos and videos in, and the first one is the location's cover. Media added
since the last arrangement comes first, newest first, which is the order every location returned before. This applies to [get a
location](/docs/developer/api/locations/get-a-location), [retrieve all locations](/docs/developer/api/locations/retrieve-all-locations), and the
location in webhook payloads.
[Update a subscription item](/docs/developer/api/subscriptions/update-a-subscription-item) with `grantedDiscounts` now keeps exactly the
coupons in the list, and an empty list removes them all. Before, a coupon the item carried as a product-type percentage discount, the
deprecated `discounts` field, came back after the update.
A resource can charge different prices on some weekdays. `pricingRules` lists the rules, each with the `days` it covers and the `money`
and `credits` tiers that replace the regular ones for a booking starting on one of those days, in the location's time zone. Pass it when
you [create a resource](/docs/developer/api/resources/create-a-resource) or [patch a resource](/docs/developer/api/resources/patch-a-resource): the
list replaces the current rule, an empty list removes it, and a patch without it keeps it. The list holds at most one rule, a rule must
select at least one day, and a rule keeps only the prices the resource charges, so its `money` tiers are dropped while money is disabled
and its `credits` tiers while credits are disabled. [Get a resource](/docs/developer/api/resources/get-a-resource) returns the rules, and
[create a booking](/docs/developer/api/resources/create-a-booking) prices the booking with the rule covering its start day. Dynamic pricing
still applies on top of the day's tiers.
Invoice items carry `issueDate`, when their invoice was issued. It is returned once the item is on an issued invoice: [list invoice
items](/docs/developer/api/billing/list-invoice-items), [retrieve an invoice item](/docs/developer/api/billing/retrieve-an-invoice-item), [retrieve
an invoice](/docs/developer/api/billing/retrieve-an-invoice), and [issue an invoice](/docs/developer/api/billing/issue-an-invoice).
[List invoice items](/docs/developer/api/billing/list-invoice-items) accepts `pending`. With `true` it returns only pending items, the ones not
on an invoice and not part of a subscription, and with `false` only the rest.
A resource can have its own booking window. [Create a resource](/docs/developer/api/resources/create-a-resource) and [patch a
resource](/docs/developer/api/resources/patch-a-resource) accept `bookingWindow`, and [get a resource](/docs/developer/api/resources/get-a-resource)
and [retrieve resources](/docs/developer/api/resources/retrieve-resources) return it. While `bookingWindow.enabled` is `true`, `minNotice`, how
many minutes before it starts a booking has to be made, and `bookAhead`, how far ahead users can book (`oneDay`, `twoDays`, `oneWeek`,
`twoWeeks`, `oneMonth`, `threeMonths`, `sixMonths`, `oneYear`, or `unlimited`), replace the ones the location sets for the resource type,
and both are required. While it is `false`, the resource follows its location and keeps its own values. [Create a
booking](/docs/developer/api/resources/create-a-booking), [update a booking](/docs/developer/api/resources/update-a-booking), and [check resource
availability](/docs/developer/api/resources/check-resource-availability) apply the resource's window.
Location payloads carry how far ahead users can book in new fields, `roomBookAhead`, `deskBookAhead`, `officeBookAhead`,
`parkingBookAhead`, and `equipmentBookAhead`, with the values `oneDay`, `twoDays`, `oneWeek`, `twoWeeks`, `oneMonth`, `threeMonths`,
`sixMonths`, `oneYear`, and `unlimited`. The `roomBookingPeriod`, `deskBookingPeriod`, `officeBookingPeriod`, `parkingBookingPeriod`, and
`equipmentBookingPeriod` fields and their `BOOKING_PERIOD_*` values are deprecated and will be removed. Until then they keep the same
values. See [Webhooks](/docs/developer/webhooks).
Invoice items carry the `customer` they are billed to, with the company name in `title` for a company and the member in `user`, the same
way invoices do. It is returned wherever an invoice item is: [list invoice items](/docs/developer/api/billing/list-invoice-items), [retrieve an
invoice item](/docs/developer/api/billing/retrieve-an-invoice-item), [create an invoice item](/docs/developer/api/billing/create-an-invoice-item),
[list upcoming invoice items](/docs/developer/api/billing/list-upcoming-invoice-items), [retrieve the upcoming
invoice](/docs/developer/api/billing/retrieve-the-upcoming-invoice), [retrieve an invoice](/docs/developer/api/billing/retrieve-an-invoice), and
[issue an invoice](/docs/developer/api/billing/issue-an-invoice).
A membership's `role` is read-only. Administrators are managed on the Administrators page, so [create a
membership](/docs/developer/api/community/create-a-membership) and [update a membership](/docs/developer/api/community/update-a-membership) no
longer take `role`, and `role` is no longer required on create. A `role` sent in the request is ignored and never changes the user's
administrator access. The `role` returned by [retrieve a membership](/docs/developer/api/community/retrieve-a-membership) and the other
membership endpoints still says whether the user administers the location, and removing a membership no longer removes that access.
[Update a booking](/docs/developer/api/resources/update-a-booking) can move a booking paid by card or externally to a pricier resource with
`resourceRef`. The difference is charged as a separate money transaction, the way an extension is: the booking stays `tentative` while the
charge is pending, and a failed charge returns it to its previous resource and interval. A move to a resource with a lower price is still
rejected with `bookingMovePriceMismatch`, and a move while an extra charge is pending is rejected with `bookingPaymentPending`.
Ticket comment and guide attachments can be uploaded through the API. Create an upload for a file of any type up to 50 MB with [ticket
comments](/docs/developer/api/support/create-a-ticket-media-upload) or [guides](/docs/developer/api/guides/create-an-attachment-upload), send the
file to the presigned URL with the headers returned, then pass the returned key in `activity.attachments` when you [create a ticket
comment](/docs/developer/api/support/create-a-ticket-comment) within 25 minutes, or in `attachments` when you [create a
guide](/docs/developer/api/guides/create-a-guide) or [update a guide](/docs/developer/api/guides/update-a-guide) within an hour. A key that is
unknown, expired, already attached, or uploaded by another network now fails with `400` and the code `fileUploadNotFound`, where a ticket
comment returned `404` and a guide dropped the attachment, and one whose file is still in transit fails with `409` and
`fileUploadPending`. See [File uploads](/docs/developer/api/file-uploads) for the full flow.
[Retrieve resource assignments](/docs/developer/api/resources/retrieve-resource-assignments) no longer returns an assignment that a
subscription reserved during a checkout that expired without completing. Such a reservation never held the resource, as creating or
updating an assignment already ignored it once expired, but it stayed in the list until it was deleted, which could take days.
Check-ins are part of the API. [Retrieve check-ins](/docs/developer/api/check-ins/retrieve-check-ins) lists a location's check-ins, newest
arrival first, filtered by arrival date, `status`, `type`, or `userRef`, and [get a check-in](/docs/developer/api/check-ins/get-a-check-in)
returns one by its id. [Check in](/docs/developer/api/check-ins/check-in) records an arrival for a booking, an event ticket, a visit, or a
member's subscription, found by its check-in id, by a location and a six-digit code, or by a location and a `customerRef`, and [check
out](/docs/developer/api/check-ins/check-out) records the departure. They come with their own OAuth scopes: reading needs `checkIns.readonly`
or `checkIns`, and checking in or out needs `checkIns`. With a bearer token, the user must be an administrator of the check-in's location.
Contract template files can be uploaded through the API. [Create a template upload](/docs/developer/api/contracts/create-a-template-upload) for
a .docx file of up to 50 MB, send the file to the presigned URL, then pass the returned key as `template.file.key` when you [create a
template](/docs/developer/api/contracts/create-a-template) or [update a template](/docs/developer/api/contracts/update-a-template). A key that is
unknown, expired, already used, or uploaded by another network now fails with `400` and the code `fileUploadNotFound` instead of `404`,
and one whose file is still in transit with `409` and `fileUploadPending`. An update that replaces the file fails with `409` and the code
`conflict` when another request replaced it first. See [File uploads](/docs/developer/api/file-uploads) for the full flow.
Product, resource, guide, and post media and company logos can be uploaded through the API. Create an upload with
[products](/docs/developer/api/shop/create-a-media-upload), [resources](/docs/developer/api/resources/create-a-media-upload),
[guides](/docs/developer/api/guides/create-a-media-upload), [posts](/docs/developer/api/feed/create-a-media-upload), or
[companies](/docs/developer/api/community/create-a-logo-upload), send the file to the presigned URL, then attach it: `media[0].key` on a
product, a key in `media` on a resource or a post, a Markdown image with the returned `url` in a guide `description`, or `logo.key` on a
company. Guides and posts also take MP4, QuickTime, and WebM videos up to 50 MB. [Create a
company](/docs/developer/api/community/create-a-company) and [update a company](/docs/developer/api/community/update-a-company) now accept `logo`,
where `null` removes it, and companies return `logo` with its `key` and `url`. An attached key that is unknown, expired, or already used
fails with `fileUploadNotFound`, and one whose file is still in transit with `fileUploadPending`. See [File
uploads](/docs/developer/api/file-uploads) for the full flow.
A resource can have up to 10 images. `media` lists them in display order, and `imageUrl` is the URL of the first one, the resource's
cover. When you [create a resource](/docs/developer/api/resources/create-a-resource) or [patch a
resource](/docs/developer/api/resources/patch-a-resource), `media` sets the whole list in the order given, so send the current keys in a new
order to reorder the images, or an empty list to remove them all. A patch without `media` keeps the current images. Before, a patch used
only the first key in `media` and ignored an empty list. See [Get a resource](/docs/developer/api/resources/get-a-resource).
[Retrieve bookings](/docs/developer/api/resources/retrieve-bookings) sorts by cancellation with `order=deleteDate:desc` or
`order=deleteDate:asc`. The list then holds only cancelled bookings, ordered by their `deleteDate`, and `status` defaults to `canceled`.
It works with every lookup the endpoint supports, but not with `singleBookings`, which returns a validation error as it does for
`createDate`.
Location and resource schedules can stay open past midnight. A schedule item's `hours.to` is counted from the start of its weekday, so a
day open from 6:00 PM to 2:00 AM returns `from: "18:00:00"` and `to: "26:00:00"`, at most 24 hours after `from`. Parse `hours.to` as a
number of hours and minutes rather than as a time of day. Bookings inside such a day can run past midnight, and a hot desk booking spends
one day pass per seat for each schedule day it covers. See [Get a location](/docs/developer/api/locations/get-a-location) and [Get a
resource](/docs/developer/api/resources/get-a-resource).
Orders can carry the `external` payment method, which an administrator uses to record a payment collected outside Spacebring, such as cash
or a bank transfer. When [getting an order](/docs/developer/api/shop/get-an-order) or [retrieving orders](/docs/developer/api/shop/retrieve-orders),
such an order returns `payment.method.type` as `external` and the paying customer in `payment.method.external.customer`. When the payment
is recorded as still owed, `payment.status` stays `pending` until it is marked as paid. The `shop.order.created` and `shop.order.paid`
[webhooks](/docs/developer/webhooks) carry the same payment with `type` set to `external`.
[Update a booking](/docs/developer/api/resources/update-a-booking) paid by card or externally to extend it or add seats. The added part is
charged as a separate money transaction, so `payments` lists one entry per charge, the booking stays `tentative` while the charge is
pending, and a failed charge returns the booking to its previous interval instead of canceling it. Shortening such a booking is still
rejected with `bookingDurationChangeNotAllowed` for users and is not refunded for administrators, and a change to the duration or seats
while a payment is pending is rejected with `bookingPaymentPending`. See [Get a booking](/docs/developer/api/resources/get-a-booking) for the
`payments` field.
The `benefit.application.created` payload always includes the `benefit` object with the applied benefit's `id` and `title`, so an
integration no longer has to treat it as optional. No other field of the payload changes. See [Webhooks](/docs/developer/webhooks).
Shop orders paid through a payment gateway are created with the `pending` status and move to `new` once the payment succeeds. Pass
`status=pending` when you [retrieve orders](/docs/developer/api/shop/retrieve-orders) to list them; the default status filter still excludes
them. Updating a pending order fails with a validation error until its payment completes.
[Check resource availability](/docs/developer/api/resources/check-resource-availability) before creating a booking. Send the `startDate` and
`endDate` of the slot, plus `quantity` for seat-based resources such as hot desks, `entire` to check a whole office, or `recurrence` RRULE
lines for a repeating slot. The response returns `available`, and when the slot cannot be booked, a `reason` with the `code` and `message`
the booking would fail with, such as `bookingConflict` or `bookingScheduleConflict`. The same capacity, schedule, duration, and booking
window rules as booking creation apply.
Event cover images can be uploaded through the API. [Create a media upload](/docs/developer/api/events/create-a-media-upload) to get a
presigned URL, send the file to it, then pass the returned `key` as `media[0].key` when creating or updating an event. Creating or
updating an event with a key that is unknown, not yet uploaded, or expired now fails with the `fileUploadNotFound` code, or
`fileUploadPending` while the file is still in transit, instead of saving the event without an image. See [File
uploads](/docs/developer/api/file-uploads) for the full flow.
Transactions share one response format across credits, day passes, and money, and money transactions can now be updated and refunded through the API:
* **All transaction responses**: `customer` identifies the company or user the transaction belongs to, `product` links the transaction to its booking, ticket, order, invoice, or subscription and carries a display `title`, and `userCreatedBy` names who created it
* **Credits and day pass transactions**: `amounts` splits a charge across the expiring and permanent balances it was deducted from
* **Money transactions**: `payment` carries the payment method, price, surcharge, refunds, dispute, and whether the payment is still refundable, alongside top-level `currencyCode`, `customerName`, `customerTaxId`, `customerAddress`, and `receiptPdfUrl`
* **New money routes**: [update a money transaction](/docs/developer/api/transactions/update-a-money-transaction) to approve or cancel a pending external payment, and [refund a money transaction](/docs/developer/api/transactions/refund-a-money-transaction) fully or partially through the payment gateway it was paid with
The previous fields are deprecated and will be removed in a future release:
* `membershipRef`, `companyRef`, `company`, `user`, and `userOwner` — use `customer` and `customer.user` instead
* `membershipRefCreator`, `userCreator`, and `userRefCreator` — use `userCreatedBy` instead
* The `booking`, `ticket`, `order`, `invoice`, `plan`, and `creditPackage` embeds — use `product` instead
* `expiringAmount` and `permanentAmount` on credits transactions — use `amounts` instead
* `paymentMethod`, `refund`, `refunds`, `billingAddressBy`, and `billingAddressTo` on money transactions — use `payment.method`, `payment.refunds`, `locationAddress`, and `customerAddress` instead
* `membershipRef` and `companyRef` in transaction list queries and in create credit or day pass transaction requests — pass `customerRef` instead
The deprecated fields keep working for now, so existing integrations are not affected. We recommend migrating to the new fields at your earliest convenience.
Create booking requests accept a `paymentMethod` with the `external` type to record a payment collected outside Spacebring. Pass
`external.status` as `succeeded` to confirm the booking, or `pending` to keep it tentative until the payment is marked as paid. Spacebring
issues the invoice once the payment is confirmed.
New webhook event types for events, alongside the existing `event.created`:
* `event.updated` — sent when an event's details change
* `event.canceled` — sent when an event is canceled
* `event.deleted` — sent when an event is deleted
The event payload now includes `cancelDate` and `deleteDate`. Select the new event types for your endpoint in **Network Settings** > **Developers**.
Support ticket assignees are now users instead of memberships. The membership-based assignee fields are deprecated and will be removed in a future release:
* **Ticket responses**: `membershipAssignee` and `membershipRefAssignee` are deprecated — use `userAssignee` and `userRefAssignee` instead
* **Ticket activity responses**: `data.membershipAssignee` and `data.previousAttributes.membershipAssignee` are deprecated — use `data.userAssignee` and `data.previousAttributes.userAssignee` instead
* **Update ticket assignee requests**: `ticket.membershipRefAssignee` is deprecated — pass `ticket.userRefAssignee` with the ID of the user to assign, or `null` to unassign
The deprecated fields keep working for now, so existing integrations are not affected. We recommend migrating to the user-based fields at your earliest convenience.
New API routes for floors management:
* Retrieve a list of all floors
* Delete a floor
New Discounts section with API routes for coupons and promocodes:
* Retrieve, create, get, update, and delete coupons
* Retrieve, create, get, and archive promocodes
* Retrieve promocode redemptions
New API routes for credit notes management:
* Issue, preview and update credit notes
New API routes for invoice management:
* Update, delete, duplicate, issue, void, and resend invoices
* Cancel a payment on an invoice
* Retrieve an upcoming invoice preview
* Search invoices by code or number
New API routes for invoice item management:
* Retrieve, update, and delete invoice items
* List invoice items by invoice, scheduled, or upcoming
New API routes for guide management:
* Retrieve a single guide or list of all guides
* Add, modify, and delete guides
Manage subscriptions with ease! With new API routes, you can:
* Retrieve subscription data
* Add, modify, and delete subscription items
* Patch subscription details, as advance invoicing, pause payment collection etc.
Streamline your subscription management and enhance customer experience!
Check out new ways to manage visitors! With new API routes, you can:
* Check in and check out visitors
* Create visit requests
* Approve and reject requests
* Register contacts
Build better community with your customers using new capabilities!
Comprehensive social feed management capabilities:
• **Feed Posts Management**
– Create, retrieve, update, and delete feed posts seamlessly
– Browse all posts with filtering by hashtags and pagination
• **Interactive Comments System**
– Add, retrieve, and manage comments on any feed post
– Enable rich discussions and community engagement
• **Social Engagement Features**
– Like and unlike both posts and comments
Build dynamic social experiences and foster community engagement with these powerful feed management tools!
Introducing comprehensive support and subscription management capabilities:
• **Support**
– Open, update, and close support tickets effortlessly
• **Subscription Plans**
– Create, modify, and monitor customer plans
Unlock new possibilities for customer service and subscription management with these robust tools!
Major expansion in product catalog and event coordination features:
• **Product & Order Management**
– Add or modify products with a single call
– Place, track, and update orders seamlessly
• **Event Management**
– Schedule events, manage details, and publish updates
Transform how you handle events—streamline operations like never before!
Powerful new capabilities for benefits administration and visitor insights:
• **Benefits & Applications**
– Create, organize, and update benefit and their categories
– Submit and review user applications in one go
• **Visitor Tracking**
– Capture and query visitors data
Enhance your platform with better benefits and visitor management!
Introducing New API & Webhooks
We’re thrilled to introduce the newly redesigned Spacebring API, built from the ground up to help you create more powerful, seamless integrations and automated workflows.
Expanded Endpoints: Take advantage of the restructured existing endpoints and many new ones to build more flexible, custom integrations.
Webhook Support: Receive real-time event notifications, enabling faster and more responsive interactions.
Improved Documentation: Get up and running with the development process more quickly thanks to helpful explanations in our newly added guides.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.