Accommodation

Overview

The Accommodation module is the core of Ananas GDS for hotels, resorts, and apartment complexes. An accommodation account can manage one or more Properties, and each property is a self-contained data unit that holds all the information a tour operator or travel agent needs to work with that property.

Each property contains:

• A complete fact sheet split across 12+ structured categories covering everything from general information and location through to rooms, food & beverage, sports, entertainment, and policies.
• A photo gallery with CDN-hosted images, category tagging, and a selectable feature image.
• A stop sale calendar for managing availability, allotments, and room-level blockouts (handled by the Stop Sale module — see Stop Sale).
• Partner connections via active contracts, controlling which tour operators receive data and which categories they can read.
• A publishing workflow that governs when edited fact sheet data becomes visible to connected partners.

Accommodation accounts are the data-producing side of the platform. Everything they enter flows downstream to tour operators who consume it via authenticated API calls using partner tokens.

Property Model

A Property record represents a single accommodation unit — a hotel, resort, apartment block, or villa complex. It is the top-level anchor for all fact sheet data, photos, and partner connections.

Property Access Rules

Access to property records is controlled at two levels:

• Owner: the account manager can access all properties belonging to their account.
• Sub-user: can only access properties explicitly granted via a SubUserPropertyAccess record. If no access rows exist for a sub-user, they see all properties of their manager as a fallback.

Property Endpoints

All property endpoints require session or token authentication. Sub-users are filtered to their permitted property set automatically.

Returns a list of all properties accessible to the authenticated user. Manager accounts see all their properties; sub-users see only granted properties.

Returns the detail record for a single property by ID.

Creates a new property. After creation, call /api/facts/init-facts-info/{info_id}/ to initialise all fact sheet category records for the new property.

Full update of a property record. Requires all fields to be present.

Permanently deletes a property and all associated fact sheet data, photos, and partner connections. This action cannot be undone.

Full-text search across property names and locations. Accepts a q query parameter.

Fact Sheet

A fact sheet is the complete, structured description of a property. It is divided into independent categories, each of which has its own endpoint. Categories are separated into two types depending on how they relate to the property: OneToOne records (one per property) and Array records (multiple rows, replaced on save).

All fact sheet data is scoped to a property via a hotel field. On GET requests this is passed as a query parameter (?hotel={property_id}); on POST requests the property ID is included in the request body.

OneToOne Fact Categories

These categories hold a single record per property. A GET retrieves the existing record; a POST creates or overwrites it. All endpoints accept GET ?hotel={property_id} and a POST body that includes the property ID.

Array Fact Categories

Array categories hold multiple rows for a single property. Unlike OneToOne categories, a POST to an array endpoint deletes all existing rows for that property and recreates them from the submitted payload. This means you must always submit the complete desired set of records, not a diff.

Rooms

Room types use a different pattern from the two above. Rather than full-replacement on save, rooms support individual upsert (create-or-update) and single-row delete. This allows hotel staff to add, edit, or remove a single room type without affecting the rest.

Returns all room type records for the specified property.

Upserts a single room record. Include id: 0 in the payload to create a new room. Include an existing room's id to update it in-place.

Deletes a single room type record by its ID.

Room records include the following key fields:

• name — room type name as displayed to partners
• category — room class (standard, superior, suite, etc.)
• count — total number of units of this type at the property
• size_sqm — floor area in square metres
• beds — bed configuration description
• view — view type (sea view, garden view, pool view, etc.)
• floor info — available floor levels
• features — amenities checklist (balcony, air conditioning, safe, etc.)

Photo Gallery

Each property has an independent photo gallery. Photos are stored via ImageKit CDN, which provides fast delivery, on-the-fly transformations, and permanent deletion via file ID. The gallery supports categorisation, metadata, and a single designated feature image shown as the property thumbnail across the platform.

Gallery Management Endpoints

Returns all photo records for the specified property, including CDN URLs, metadata, and the featured flag.

Uploads a new photo to ImageKit and creates a gallery record. The request must be a multipart/form-data submission. Returns the new photo record including the assigned CDN URL.

Updates metadata for an existing photo: title, description, and category tags. Does not replace the image file itself.

Deletes the photo record and removes the image from ImageKit using the stored file ID. This action is permanent and cannot be undone.

Sets a specific photo as the property's feature image. Updates Property.hotel_image to point to the selected photo ID. Only one photo can be featured at a time.

Returns a count of photos per property for the authenticated account. Useful for dashboard display and quota checks.

Export & Distribution Endpoints

Accommodation managers can export or email the photo gallery for a property.

Downloads all gallery photos for the property as a single ZIP archive. Photos are fetched from ImageKit and bundled server-side before streaming to the client.

Sends the photo gallery to all recipients in a saved mailing list. Attach the mailing_list_id of the target list and the property_id of the property whose photos you want to distribute.

Partner Photo Access

Tour operators with an active partner token access photos through a separate public endpoint. No session authentication is required — the token itself is the credential.

Returns all published gallery photos for the property associated with the given partner token. The response includes CDN URLs suitable for direct display or download.

Publishing & Approval Workflow

Fact sheet data entered by hotel staff is not immediately visible to partners. Before partner API calls return updated content, the fact sheet must go through a publish and approval workflow. This ensures data quality and prevents incomplete edits from being distributed to tour operators.

Publishing States

A fact sheet version moves through four states:

1. Draft — the fact sheet has been edited by hotel staff but not yet submitted. Changes are stored and visible in the hotel dashboard but not distributed to partners.
2. Pending — the hotel has submitted the fact sheet for review. A pending record is created and awaits approval by a platform manager or admin.
3. Approved — a manager or admin has approved the submitted version. The fact sheet becomes the live published version and is immediately available to partners via the API.
4. Declined — a manager or admin has declined the submission. The hotel receives feedback, revises the fact sheet, and resubmits.

Publishing Endpoints

Submits the current draft fact sheet for this property for review. Moves the state to Pending and creates a publish record. Requires the publishing_manager permission flag for sub-users.

Returns the currently approved (live) published facts for a specific category (info_type) of the given property. Use this to see exactly what partners receive.

Returns the date and time of the most recent approved publish for each property belonging to the authenticated account. Accepts an optional hotel query parameter to filter to a single property.

Admin Review Endpoints

These endpoints are restricted to platform staff with the relevant admin permission.

Lists all pending publish requests across all accommodation accounts. Returns property name, submission timestamp, and submitting user.

Returns a full preview of the fact sheet changes included in a specific pending publish request, compared against the currently live version.

Approves a pending publish. The submitted fact sheet version immediately becomes live. Partners accessing the API after approval will receive the updated data.

Declines a pending publish. An optional reason can be included in the request body. The property's fact sheet returns to Draft state and the hotel is notified.

Partner Access to Published Facts

Returns the full approved fact sheet for the property associated with the given partner token. Only approved data is returned — draft or pending versions are never exposed through this endpoint. This is the primary endpoint tour operators use to pull structured property data.

Export & Distribution

Accommodation providers can export and distribute fact sheet data outside the platform for partners who are not yet using the Ananas GDS API directly. Two distribution methods are available: PDF download and email delivery to a mailing list.

Generates and downloads a PDF fact sheet for the property. The PDF is built from the currently approved (published) fact sheet data. Layout and branding follow the platform's PDF template engine. Requires the publishing_manager permission flag for sub-users.

Emails a PDF fact sheet to all recipients saved in the specified mailing list. The mailing_list_id must belong to the authenticated account. Delivery is handled asynchronously via Celery. Requires the publishing_manager permission flag for sub-users.

Initialise Fact Sheet

When a new property is created, its associated fact sheet category records do not exist yet. Before any category data can be saved, all fact records must be initialised for the property. This is done by calling the init endpoint immediately after the property creation step.

Creates empty placeholder records for all OneToOne fact categories linked to the property identified by info_id. This endpoint is idempotent — calling it on a property that already has initialised records will not overwrite existing data.

Returns the complete fact sheet for the given property as a single JSON object, with all categories merged under their respective keys. Useful for generating exports, previews, and diagnostic checks of the full property data payload.

Sub-User Access

Accommodation accounts can create sub-user accounts for team members such as Revenue Managers, Front Office staff, and PR contacts. Sub-users share the manager's account data but are restricted by granular permission flags and optional property-level access grants.

Required Permission Flags

Each action category in the Accommodation module is gated by a separate flag on the UserPermission record. If a sub-user lacks the required flag, the relevant endpoints return 403 Not permitted.

Property-Level Restriction

In addition to permission flags, sub-users can be restricted to a specific subset of properties via SubUserPropertyAccess records. Each record links a sub-user to a single property, effectively scoping all fact sheet, photo, and stop sale operations to that property only.

If a sub-user has no SubUserPropertyAccess rows, they fall back to seeing all properties belonging to their manager. This means property-level restriction is optional — an account manager can choose to grant a sub-user access to all properties by simply not creating any property access rows for that sub-user.