> For the complete documentation index, see [llms.txt](https://dev.realpadsoftware.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://dev.realpadsoftware.com/integrations/data-takeout.md). # Data Takeout This guide describes how to use the Realpad Takeout API to back up the data stored in the system. Both structured data (such as lists of customers, deals, etc) and files uploaded to the CRM (unit plans, contract scans, ...) can be automatically retrieved this way. You are encouraged to implement an automatic backup system that will download the data from our server at any frequency you prefer, and use the data as a source for a reporting solution, or any other purpose. ## Prerequisites To use these APIs you need to have the ability to execute HTTP requests either from the command line or from some scripting language. Please contact us if you need our help with achieving this. ## OpenAPI specification Lives [here](https://openapi.gitbook.com/o/UuR2VSBNcvrkwmPVWwiM/spec/realpad-api-takeout.yaml). ## Request First of all please contact to obtain the credentials to use the Takeout API endpoints. You will perform **POST** requests over **HTTPS** and then store the resulting data. Every endpoint requires `login` and `password`; most also accept optional filtering parameters — see [Filtering Parameters](#filtering-parameters) below for the shared grammar, and the [parameter matrix](#endpoint-parameter-matrix) for what each endpoint accepts. *Example call in **cURL:*** ```bash curl \ --data "login=...&password=..." \ --output customers.xls \ https://cms.realpad.eu/ws/v10/list-excel-customers ``` ## Response #### Entity Relationship Overview The following diagram shows how the entities exported by the Takeout API relate to each other via their ID columns. Each box represents one export endpoint, and the arrows indicate which ID columns can be used to join data across exports. **Legend:** * **PK** — the entity's own identifier * **FK** — a foreign key that can be joined to another export * **"CS · default on/off"** — the column is subject to Column Selection and may be absent if the API user has de-configured it (see Column Selection below) * **"enum"** — a lookup/classification ID, not a joinable entity reference * **"→ User"** — references a User entity that is not directly exported by the Takeout API
{% file src="/files/UWNzE1uxtjOp6elDGweJ" %} #### Column Selection Some exports support **Column Selection**, which allows the API user to configure which columns appear in the output and in what order. Columns marked as "CS" in the diagram above may be absent if the API user has removed them from their column set. Most CS-dependent ID columns are **included by default** — they will be present unless explicitly de-configured. The exception is **Task → Inquiry ID**, which is off by default. Columns listed as "always present" have no Column Selection mapping and will always appear at the end of the export, regardless of configuration. ## Filtering Parameters Most endpoints below accept one or more optional filtering parameters, all sharing the same grammar: * **Date parameters** (e.g. `creationdatefrom`, `timestampto`) use the `YYYY-MM-DD` format, e.g. `2022-12-31`. An unparseable value is silently treated as absent rather than rejected. Unless an endpoint's own notes say otherwise, both bounds of a date range are inclusive, at date granularity — a `...to` date covers the whole day — and are read in the time zone of the credentials you call with. * A range whose `...to` precedes its `...from` can never match a row, so it is **rejected with `400 Bad Request`** rather than returning an empty file. * A date filter matches only rows that **carry** a date. Where the underlying field is optional — an unset Task deadline, an unplanned Inspection, an unsigned Document — rows without a value are left out of every range, including one that would otherwise cover them, and nothing in the response reports how many were omitted. A set of windowed exports therefore does not add up to the full set, and the remedy is to omit both parameters of the pair. Every such range is marked **°** in the matrix below; the `creationdate` and `timestamp` ranges are unmarked because those dates are always present. * **ID-list parameters** (e.g. `projectids`, `statusids`, `typeids`) take a comma-separated list of integers, e.g. `12,45,103`. A malformed or unrecognized value in the list is silently dropped rather than causing an error — it will simply match no rows. * **`fulltext`** is a free-text search across the same fields as the search box above the corresponding table in the Realpad CRM interface. A search of at least 6 characters typically bypasses the rate limiter — see Rate Limiting below. ## Rate Limiting Most Excel export endpoints enforce a **5-minute cooldown**, keyed per `(endpoint, credential)` pair — calling a different endpoint, or using different credentials, has its own independent cooldown. Most endpoints waive the cooldown entirely for a request that puts a **ceiling** on how much data can come back. Any one of these three criteria is enough: * exactly one `projectids` value; * a date range with **both** ends supplied, spanning **at most one year** — where an endpoint offers several ranges, any one of them qualifying is enough; * a `fulltext` search of at least 6 characters. A criterion that merely *narrows* the result without capping it does **not** waive the cooldown — a `statusids`, `typeids` or `stateids` set, or a date range with only one end supplied. A half-open range bounds nothing, and a range wider than a year is the whole history with dates on it. Waiving the cooldown neither resets nor consumes the window. The **Bypass** column in the table below names the criteria each endpoint accepts. {% hint style="warning" %} Treat these specific thresholds (6 characters, one year, …) as guidance, not a contract — they may tighten over time. The rate limiter's state is also kept in memory per application server, so it is not shared across a cluster and resets on every redeploy. {% endhint %} {% hint style="info" %} If you call a rate-limited endpoint too often, you will receive `429 TOO MANY REQUESTS` and the body of the response tells you when it will be possible to call it again. **See also:** [Authentication & Error Handling](/integrations/readme/authentication-and-error-handling.md) for details on the `Retry-After` header, banning behavior, `415 Unsupported Media Type`, and other shared error responses. {% endhint %} ### Endpoint × Parameter Matrix In the **Bypass** column, *1 Project* means exactly one `projectids` value, *closed range* means one of the endpoint's date ranges with both ends set and spanning at most a year, and *`fulltext`* means a search of at least 6 characters. Any one of the listed criteria waives the cooldown. | Endpoint | `projectids` | `fulltext` | Date ranges | ID / mode filter | `formatforsplitting` | Rate-limit bypass | | -------------------------------------- | ------------------------------------ | --------------- | ------------------------------------------------------- | ---------------------------- | -------------------- | ----------------------------------- | | `list-excel-projects` | – | ✓ | – | – | – | `fulltext` | | `list-excel-products` | ✓ | ✓ | – | – | – | 1 Project, `fulltext` | | `list-excel-project-units-history` | `projectid` (**required**, singular) | – | `timestamp` | – | – | not rate limited | | `list-milestones` (XML) | – | – | – | – | – | not rate limited | | `list-excel-customers` (deprecated) | – | ✓ | – | – | ✓ | `fulltext` | | `list-excel-customers-contacts` | – | ✓ | `creationdate` | – | ✓ | closed range, `fulltext` | | `list-excel-customer-consents` | – | ✓ | `obtainedon`° | – | – | closed range, `fulltext` | | `list-excel-inquiries` | ✓ | ✓ | `creationdate` | `statusids`, `salesagentids` | – | 1 Project, closed range, `fulltext` | | `list-excel-favorite-units` | ✓ | ✓ | `creationdate` | – | – | 1 Project, closed range, `fulltext` | | `list-excel-prereservations` | ✓ | – (unsupported) | `creationdate` | `statusids` | – | 1 Project, closed range | | `list-excel-tasks` | ✓ | – (unsupported) | `deadline`°, `finishedon`°, `creationdate` | `typeids`, `stateids` | – | 1 Project, closed range | | `list-excel-events` | ✓ | ✓ | `timestamp` | `typeids` | – | 1 Project, closed range, `fulltext` | | `list-excel-business-cases` | ✓ | ✓ | `creationdate` | `statusids` | – | 1 Project, closed range, `fulltext` | | `list-excel-deal-documents` | ✓ | ✓ | `signaturedate`° | `typeids` | – | 1 Project, closed range, `fulltext` | | `list-excel-additional-products` | ✓ | ✓ | `signaturedate`°, `deadline`° | – | – | 1 Project, closed range, `fulltext` | | `list-excel-inspections` | ✓ | ✓ | `ready`°, `planneddate`°, `actualdate`° | `typeids` | – | 1 Project, closed range, `fulltext` | | `list-excel-defects` | ✓ | ✓ | `receivedon`°, `deadline`°, `fixedon`°, `creationdate`° | `mode` | – | not rate limited | | `list-excel-payments-prescribed` | ✓ | ✓ | `deadline`° | `typeids` | – | 1 Project, closed range, `fulltext` | | `list-excel-payments-prescribed-lines` | ✓ | ✓ | – | – | – | 1 Project, `fulltext` | | `list-excel-payments-incoming` | ✓ | ✓ | `creationdate` | – | – | 1 Project, closed range, `fulltext` | | `list-resources` (XML) | – | – | – | – | – | not rate limited | Every date range is spelled as a pair of parameters — `creationdate` means `creationdatefrom` and `creationdateto`, and so on. **°** marks a range over a date that is **optional** on the record. Rows carrying no such date fall outside every range on it, including one that would otherwise cover them, and the omission is not reported — see [Filtering Parameters](#filtering-parameters). A range with no ° is safe: that date is always present, so it excludes nothing on that account. ### Endpoints with XML payload **list-resources** This endpoint provides a full list of all the files that were ever uploaded to the CRM for the given real estate developer, whether it’s unit plans, contract scans, invoices, or any other similar data that started out as a file on someone’s computer before being imported into Realpad. We call all such files ***resources***, and the `list-resources` endpoint shows them like this: The root element is ``, sub-elements look like this: ```makefile ``` * `uid` is the unique identifier of this resource, by which it can be retrieved using `get-projects`. * `content-type` is the MIME type of the file, resolved when uploaded to the system (it's the best guess). * `file-name` is the original file name when it was uploaded to the system. * `size` is the file size in bytes. * `crc` is the CRC32 checksum of the file. The basic use case for this endpoint is to back up all the files from the CRM to some storage on local infrastructure. For that, you might want to build a tool that will regularly fetch this endpoint, compare its results to the files you already have stored, and fetch the ones that are missing. You may rely on UID as the unique identifier to distinguish between the files. You can fetch resources using **HTTP GET** by retrieving a URL in the following form: `https://cms.realpad.eu/resource/` *Example call in **cURL:*** ```bash curl \ --output cached_resource \ https://cms.realpad.eu/resource/bd5563ae-abc... ``` ### Endpoints with a binary payload All of these endpoints return a single Excel file with a `.xls` extension, containing all the relevant data stored in our system. These endpoints behave just like `get-resource`, in that the HTTP headers contain a reasonable file name (e.g. when running from a web browser). **Newer Excel format:** if an extra parameter `xlsx` is sent with a non-empty value, Takeout API will instead provide the data in the Excel newer `.xlsx` format. **Column identifiers:** by default (or with `headermode=default`), the Excel file will have the header row built the same way as if the given user clicked a button to download the file in the user interface: one row, with each column titled in the language of the invoking user, using a user-friendly string. There are several other possible values for `headermode`: * `labels` behaves the same as the default, for almost every column — one row of localized column titles. (It differs from `default` only on a handful of Attribute columns, where `default` appends the attribute's internal key in parentheses.) * `ids` will export headers as one row with the columns identified by special strings that are guaranteed to be stable. * `labels_ids` will export headers as two rows: localized names first, special strings second. * `ids_labels` will export headers as two rows: special strings first, localized names second. {% hint style="warning" %} **Use `headermode=ids` for any automated integration.** The `default` and `labels` header strings are localized to the language of whichever user's credentials you're calling with, and can be retranslated at any time without notice — they are not a stable contract. The `ids` strings are: they are a deliberate, versioned identifier that will not be renamed. If you omit `headermode` entirely, you get the unstable, localized form. `ids_labels` is a reasonable choice if a human will also be reading the file. {% endhint %} ### Splitting-friendly output (`formatforsplitting`) `list-excel-customers` and `list-excel-customers-contacts` accept an optional `formatforsplitting` parameter that reformats address columns (and, on `list-excel-customers` only, the *Last Interaction* column) into a fixed, machine-parseable shape. The parameter is read for **presence, not truthiness** — `formatforsplitting=false` and `formatforsplitting=0` both enable it, the same as any other value. The only way to get the human-friendly format is to omit the parameter entirely. **Addresses**, with the parameter **off**, are comma-separated and drop empty components; the exact order and grouping depends on the tenant. A small number of specifically configured tenants (referred to below as Tenant Group A and Tenant Group B — which tenants these are is not published here) use non-default orderings: | Tenant | Format | | -------------- | -------------------------------------------------------------------------- | | Tenant Group A | `street, "zip city", state, note` (zip and city merged into one component) | | Tenant Group B | `street, zip, city, state, note` | | everyone else | `street, city, zip, state, note` | With the parameter **on**, addresses are always exactly **5** pipe-separated components, with empty components preserved: | Tenant | Format | | ------------------------------- | -------------------------------- | | Tenant Group A / Tenant Group B | `street\|zip\|city\|state\|note` | | everyone else | `street\|city\|zip\|state\|note` | *Example (a Prague address with no note, on a tenant outside Groups A/B):* * Off: `Wenceslas Square 1, Prague, 11000` * On: `Wenceslas Square 1|Prague|11000||` **Last Interaction** (only exported by `list-excel-customers`) is reshaped the same way: * Off: `{salesAgent}: {type} ({date}) {note}` * On: `{salesAgent}|{type}|{date}|{note}` — always exactly 4 pipe-separated fields, with an empty note preserved. `list-excel-customers-contacts` does not export a Last Interaction column, so there the parameter affects addresses only. {% hint style="warning" %} The pipe-separated format is **not escaped**. A literal `|` character inside an address line or an interaction note will produce an extra field. {% endhint %} {% hint style="info" %} If you call the endpoints too often, you will receive `429 TOO MANY REQUESTS` and the body of the response tells you when it will be possible to call it again. **See also:** [Authentication & Error Handling](/integrations/readme/authentication-and-error-handling.md) for details on the `Retry-After` header, banning behavior, `415 Unsupported Media Type`, and other shared error responses. {% endhint %} **list-excel-projects** Each row represents one **Project**. Always-present ID columns: * Project ID **list-excel-products** Each row represents one **Unit** (also called Product). Always-present ID columns: * Unit ID * Type ID (enum) * Availability ID (enum) * Project ID → Projects * Deal ID → Deals See the appendix for the unit type and availability enums. **list-excel-project-units-history** Accepts an additional required parameter `projectid`, which has to be a valid project ID from the Realpad database. Each row represents one **Unit History Entry** (a snapshot of a Unit's state at the time of a change). Always-present ID columns: * Project ID → Projects * Unit ID → Units * Changed By ID → User * Deal ID → Deals The first column contains the timestamp of when the given unit started containing the data on the given row. The second column contains the name of the user who caused that data to be recorded. Accepts a `timestampfrom`/`timestampto` range. Both bounds cover their own day, but `timestampfrom` is compared strictly after midnight, so a change recorded at exactly `00:00:00` on that date is excluded. {% hint style="info" %} The exported timestamp column carries the date only, so a window narrower than a single day cannot be reconstructed from the result. {% endhint %} **list-excel-customers-contacts** Each row represents one **Customer Contact**. Always-present ID columns: * Customer\~Contact ID (referenced as "Customer ID" in other exports) * Owner ID → User * Deal IDs → Deals * Related Customer IDs → Customer Contacts Supports `formatforsplitting` — see [Splitting-friendly output](#formatforsplitting) above. **list-excel-customer-consents** Each row represents one **Customer Consent**. A Customer holding several consents appears on several rows, and consents that have already expired are included, so that renewals can be tracked. An empty expiration date means the consent is **permanent**. Always-present ID columns: * Customer ID → Customer Contacts * Consent Type ID — the numeric Consent Type ID accepted by `create-lead`, `set-customer-consent` and `revoke-customer-consent` {% hint style="info" %} For large exports, request `xlsx` — the legacy `.xls` format holds fewer rows per sheet, and long exports are split across several sheets. {% endhint %} **list-excel-inquiries** Each row represents one **Inquiry**. Always-present ID columns: * Inquiry ID (column named "Inquiry") * Customer ID → Customer Contacts * Referral ID (enum) * Status ID (enum) The `statusids` and `salesagentids` values are tenant-specific — take them from the *Status ID* and *Sales Agent ID* columns of this same export. Neither set waives the cooldown on its own; they narrow the result without capping it. **list-excel-favorite-units** Each row represents one **Favorite Unit** (a Customer's expressed interest in a specific Unit). Always-present ID columns: * Inquiry ID → Inquiries * Customer ID → Customer Contacts * Unit ID → Units * Project ID → Projects * Sales Agent ID → User * Created By → User The `creationdate` range filters on the date the Customer marked the Unit as a favorite. Every Favorite Unit carries one, so no row is silently excluded. **list-excel-prereservations** Each row represents one **Pre-reservation** (a time-limited hold on a Unit before a Deal is created). Always-present ID columns: * Customer ID → Customer Contacts * Unit ID → Units * Project ID → Projects {% hint style="warning" %} **The creation date is the date of the** ***first*** **hold, not of the current one.** A Pre-reservation is recycled per Customer and Unit: pre-reserving a Unit a Customer had held before updates the existing record rather than creating a second one, and the creation date is never rewritten. So `creationdatefrom`/`creationdateto` selects on when that Customer first pre-reserved that Unit — a hold cancelled in 2024 and taken again this month still has a 2024 creation date, and falls outside a window covering this month. {% endhint %} Every Pre-reservation carries a creation date, so no row is silently excluded on that account. This endpoint accepts no `fulltext`, so one Project or a closed `creationdate` range are the only ways to waive the cooldown.
Pre-reservation status IDs (statusids) — 5 values | ID | Name | Meaning | | -- | --------- | ---------------------------------------------------------------- | | 1 | ACTIVE | alive and well | | 2 | CANCELLED | actively cancelled by the customer (or an agent on their behalf) | | 3 | LOST | cancelled by losing to someone else | | 4 | WON | cancelled by winning the pre-reservation | | 5 | EXPIRED | cancelled by expiring |
**list-excel-tasks** Each row represents one **Task**. Does **not** support `fulltext` filtering. Of the three date ranges, prefer `creationdate` when you want a slice of *all* Tasks rather than a slice of the ones that happen to carry a deadline. Always-present ID columns: * Task ID * Customer ID → Customer Contacts * Salesman ID → User (not exported) Column Selection ID columns (default: off): * Inquiry ID → Inquiries
Task type IDs (typeids) — 11 values, ungated | ID | Name | ID | Name | | --- | ----------------- | --- | -------------- | | 1 | CUSTOMER\_MEETING | 2 | CUSTOMER\_CALL | | 3 | PAYMENT\_URGE | 4 | CONTRACT\_SIGN | | 5 | LEAD\_PROCESS | 6 | CUSTOMER\_MAIL | | 7 | APARTMENT\_TOUR | 8 | SEND\_CALL | | 9 | FOLLOW\_UP | 100 | OTHER | | 101 | ARRANGE\_MORTGAGE | | |
Task state IDs (stateids) — 3 values | ID | Name | | -- | --------- | | 1 | NEW | | 2 | DONE | | 3 | CANCELLED |
**list-excel-events** Each row represents one **Event** (a logged interaction or activity). Always-present ID columns: * Event ID * Customer ID → Customer Contacts * Inquiry ID → Inquiries * Unit ID → Units * Project ID → Projects
Event type IDs (typeids) — 55 values, non-contiguous | ID | Name | ID | Name | | --- | ------------------------------------------ | --- | ---------------------------------------- | | 1 | CUSTOMER\_CREATED | 2 | CUSTOMER\_EDITED | | 3 | CUSTOMER\_DELETED | 44 | INQUIRY\_CREATED | | 12 | INQUIRY\_REASSIGNED | 45 | INQUIRY\_EDITED | | 46 | INQUIRY\_DELETED | 23 | CUSTOMER\_ATTACHED\_TO\_DEAL | | 24 | CUSTOMER\_DETACHED\_FROM\_DEAL | 42 | CUSTOMER\_ADDITIONAL\_ATTACHED\_TO\_DEAL | | 43 | CUSTOMER\_ADDITIONAL\_DETACHED\_FROM\_DEAL | 6 | FAVORITE\_ADDED | | 7 | FAVORITE\_REMOVED | 4 | PRERESERVATION\_CREATED | | 5 | PRERESERVATION\_CANCELLED | 27 | PRERESERVATION\_EXTENDED | | 33 | PRERESERVATION\_EXPIRED | 34 | PRERESERVATION\_PROMOTED | | 8 | UNIT\_AVAILABILITY\_AVAILABLE | 9 | UNIT\_AVAILABILITY\_PRERESERVED | | 10 | UNIT\_AVAILABILITY\_RESERVED | 11 | UNIT\_AVAILABILITY\_SOLD | | 21 | UNIT\_AVAILABILITY\_NOT\_FOR\_SALE | 22 | UNIT\_AVAILABILITY\_DELAYED | | 17 | UNIT\_ATTACHED\_TO\_DEAL | 18 | UNIT\_DETACHED\_FROM\_DEAL | | 13 | DEAL\_CREATED | 14 | DEAL\_STATE\_CHANGED | | 51 | DEAL\_EDITED | 25 | DEAL\_DELETED | | 29 | INDIVIDUAL\_DISCOUNT\_UPDATED | 30 | DEAL\_CLOSED\_WON | | 31 | DEAL\_CLOSED\_LOST | 32 | DEAL\_REOPENED | | 52 | DEAL\_SHARES\_EDITED | 53 | DEAL\_CADASTRE\_DATA\_EDITED | | 54 | DEAL\_ESCROW\_DATA\_EDITED | 55 | DEAL\_MORTGAGE\_DATA\_EDITED | | 26 | DEAL\_DOCUMENT\_SIGNED | 47 | DEAL\_DOCUMENT\_CREATED | | 48 | DEAL\_DOCUMENT\_EDITED | 49 | DEAL\_DOCUMENT\_CLEARED | | 50 | DEAL\_DOCUMENT\_DELETED | 35 | DEAL\_PAYMENT\_SCHEDULE\_APPLIED | | 36 | DEAL\_PAYMENT\_PRESCRIBED\_CREATED | 37 | DEAL\_PAYMENT\_PRESCRIBED\_EDITED | | 38 | DEAL\_PAYMENT\_PRESCRIBED\_DELETED | 39 | DEAL\_PAYMENT\_INCOMING\_CREATED | | 40 | DEAL\_PAYMENT\_INCOMING\_EDITED | 41 | DEAL\_PAYMENT\_INCOMING\_DELETED | | 16 | CRM\_TASK\_COMPLETED | 28 | CRM\_TASK\_CANCELLED | | 100 | LEAD\_AUDIT\_TRACE | 101 | LEAD\_SPAM\_CHECK | | 999 | OTHER | | |
**list-excel-business-cases** Each row represents one **Deal**. Always-present ID columns: * Customer ID → Customer Contacts * Salesman ID → User * Status ID (enum) * Lifecycle ID (enum) * Main Unit ID → Units * Additional Customer IDs → Customer Contacts * Additional Product IDs → Additional Products * Project ID → Projects Column Selection ID columns (default: on): * Deal ID * Inquiry ID → Inquiries
Deal status IDs (statusids) — 4 values | ID | Name | Meaning | | -- | -------- | -------------------------------------------- | | 1 | ACTIVE | being negotiated / paid | | 2 | LOST | closed without purchasing the Unit | | 3 | WON | closed with a successful purchase | | 4 | SLEEPING | reserved, not currently produced by any flow |
**list-excel-deal-documents** Each row represents one **Deal Document** (a contract or other document associated with a Deal). To export unsigned Documents, omit both `signaturedate` parameters and bound the request with `projectids` instead. Always-present ID columns: * Document ID * Customer ID → Customer Contacts * Salesman ID → User Column Selection ID columns (default: on): * Deal ID → Deals
Deal Document type IDs (typeids) — 20 of the values, by ascending ID plus the catch-all types This lists 20 of the values (by ascending ID, plus the generic catch-all types at the end) — not the full enum. The full `DealDocumentType` list runs past 100 constants, most of them narrow and tenant-specific. Which of these a given tenant can produce also varies a lot. | ID | Name | ID | Name | | --- | ------------------------------------------ | --- | -------------------------------------- | | 1 | RESERVATION\_CONTRACT | 2 | FUTURE\_PURCHASE\_CONTRACT (FPC / PSC) | | 3 | PURCHASE\_CONTRACT (PC / SC) | 4 | SECUREMENT\_AGREEMENT | | 5 | PLEDGE\_CONTRACT | 6 | MORTGAGE\_CONTRACT | | 7 | NOTARY\_ESCROW\_CONTRACT | 8 | RESERVATION\_AGREEMENT | | 9 | ADDITIONAL\_PRODUCT\_CONTRACT | 10 | CADASTRE\_ENTRY\_CONFIRMATION | | 11 | BANK\_AGREEMENT | 13 | FPC\_ADDENDUM | | 15 | BANK\_ESCROW\_CONTRACT | 16 | AGREEMENT\_ON\_ASSIGNMENT | | 21 | INFORMATIONAL\_LETTER | 30 | RECLAMATION\_RECEIVED\_PROTOCOL | | 98 | ADDENDUM | 99 | OTHER | | 100 | RECLAMATION\_PROTOCOL\_GENERAL\_CONTRACTOR | 200 | PRODUCT\_MARKETING\_MATERIAL | FPC/PSC and PC/SC are alternate names for the same two contract types — which name a given tenant sees depends on their English localization variant, but the `typeids` value is identical either way.
**list-excel-additional-products** Each row represents one **Additional Product** (an extra item or service sold alongside a Deal). Both filtered dates are borrowed: `signaturedate` comes from the linked Document and `deadline` from the linked Payment, not from the Additional Product itself — and either link may be absent, which is why both ranges are marked °. Always-present ID columns: * Additional Product ID * Type ID (enum) * Payment ID → Prescribed Payments Column Selection ID columns (default: on): * Deal ID → Deals **list-excel-payments-prescribed** Each row represents one **Prescribed Payment** (a scheduled payment that a customer is expected to make). The `deadline` range filters on the **calculated** deadline, the same value the export returns: the Payment's own deadline where it has one, otherwise derived from its Milestone or from its Document's signature. Where none of the three yields a date — typically a Payment waiting on an undated Milestone or an unsigned Document — the row has no deadline at all, which is why the range is marked °. {% hint style="info" %} This one comparison is made in the server's time zone rather than yours, so a Payment whose deadline falls exactly on one of the two boundary days may land on either side of it. That is immaterial for the windows this filter is meant for — a month, a quarter, a year — but do not rely on it to reconcile a single day. {% endhint %} Always-present ID columns: * Payment ID * Type ID (enum) Column Selection ID columns (default: on): * Deal ID → Deals
Prescribed Payment type IDs (typeids) — 5 values | ID | Name | Meaning | | -- | ---------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | 1 | RESERVATION\_FEE | | | 5 | ADDITIONAL\_PAYMENT | | | 7 | ADDITIONAL\_PRODUCT\_PAYMENT | | | 8 | FPC\_PAYMENT | Future Purchase Contract (FPC) instalment — some tenants see this contract type labeled "Pre-sale Contract" (PSC) instead; the `typeids` value is the same either way | | 9 | FIRST\_FPC\_PAYMENT | The first FPC/PSC instalment |
**list-excel-payments-prescribed-lines** Each row represents one **Prescribed Payment Line** (a detail row within a Prescribed Payment, allocating an amount to a specific Unit). Always-present ID columns: * Line ID * Deal ID → Deals * Payment ID → Prescribed Payments * Unit ID → Units **list-excel-payments-incoming** Each row represents one **Incoming Payment** (an actual payment received from a customer). Always-present ID columns: * Payment ID * Prescribed Payment ID → Prescribed Payments Column Selection ID columns (default: on): * Deal ID → Deals **list-excel-inspections** Each row represents one **Inspection** (a scheduled or completed handover or technical inspection for a Deal). An Inspection that is not yet ready, not yet planned or not yet performed carries no date on the corresponding axis, which is why all three of its ranges are marked °. Always-present ID columns: * Row ID Column Selection ID columns (default: on): * Deal ID → Deals
Inspection type IDs (typeids) — 3 values | ID | Name | Meaning | | -- | --------------------- | ---------------------------- | | 1 | TECHNICAL\_INSPECTION | | | 2 | HANDOVER | | | 3 | INSPECTION | defect-removal re-inspection |
**list-excel-defects** Each row represents one **Defect** (a reported issue found during an Inspection or warranty period). Accepts an additional optional parameter `mode`. If omitted, the user's default reclamation mode is used. Any value other than the report mode names listed below is rejected with a 400. {% hint style="info" %} **`creationdate` is not the same axis as `receivedon`.** The creation date is when the Defect record itself was created; `receivedon` comes from the parent Warranty Claim, one level up, and is optional there. `creationdate` carries a ° only for a small number of legacy Defects with no creation date recorded — all of them years old, so a window over recent history is unaffected. {% endhint %} Always-present ID columns: * Defect ID Column Selection ID columns (default: on): * Deal ID → Deals
Report modes (mode) — 6 values, passed as the string label | Name | Meaning | | ----------------------------------- | ---------------------------------------------- | | DEAL\_DEFECTS | Deal (reclamation) defects | | DEAL\_DEFECTS\_COMMUNAL\_AREA | Deal defects in communal areas | | INSPECTION\_DEFECTS | Inspection defects | | INSPECTION\_DEFECTS\_COMMUNAL\_AREA | Inspection defects in communal areas | | DEAL\_DEFECTS\_COMBINED | Combined deal defects (specific tenants) | | INSPECTION\_DEFECTS\_COMBINED | Combined inspection defects (specific tenants) | Availability of modes depends on the tenant's feature configuration.
### Deprecated endpoints **list-excel-customers** {% hint style="warning" %} **Do not call this endpoint.** It belongs to the legacy Single Inquiry data model, and every tenant has since moved to Multiple Inquiries — so there is no longer any configuration in which its output is the right answer. Use `list-excel-customers-contacts` together with `list-excel-inquiries` instead. {% endhint %} The last column contains the unique customer ID from the Realpad database. Supports `formatforsplitting` — see [Splitting-friendly output](#formatforsplitting) above. **list-excel-unit-history** (removed) {% hint style="danger" %} This endpoint **no longer exists** — it was removed in September 2024 and a call to it now fails. It returned a single Unit's history per call, so it had to be looped over every Unit. Use `list-excel-project-units-history`, which returns the history of every Unit in a Project in one call. {% endhint %} ## Appendix
Unit status / availability IDs — 6 values | ID | Name | | -- | ------------ | | 0 | free | | 1 | pre-reserved | | 2 | reserved | | 3 | sold | | 4 | not for sale | | 5 | delayed |
Unit type IDs — 37 values | ID | Name | ID | Name | | -- | ---------------------------- | -- | -------------------------------------- | | 1 | flat | 2 | parking | | 3 | cellar | 4 | outdoor parking | | 5 | garage | 6 | commercial space | | 7 | family house | 8 | land | | 9 | atelier | 10 | office | | 11 | art workshop | 12 | non-residential unit | | 13 | motorbike parking | 14 | creative workshop | | 15 | townhouse | 16 | utility room | | 17 | condominium | 18 | storage | | 19 | apartment | 20 | accommodation unit | | 21 | bike stand | 22 | communal area | | 23 | non-residential unit - other | 24 | berth | | 25 | construction right | 26 | villa | | 27 | technical space | 28 | outdoor parking position for motorbike | | 29 | property management unit | 30 | attic | | 31 | backyard | 32 | terrace | | 33 | cubicle | 34 | tenement house | | 35 | paved area | 36 | garage position | | 99 | other | | |
‍ {% @mailchimp/mailchimpSubscribe cta="Sign up to receive updates!" %}