Flatfox

POST https://be-api.admin.evorest.ch/webhook/flatfox

The inbound body is the shared open-a-deposit payload. Three things differ.

Response

On top of success, result, and reason, the response carries tenantRegistrationUrl, the link where the tenant registers with Evorest:

{
  "success": true,
  "result": "success",
  "tenantRegistrationUrl": "https://www.tenant-app.evorest.ch/de/register?email=tenant%40example.com"
}

The path segment before register is the tenantLanguage you sent, and the query is the tenant’s email. Always send tenantLanguage (de, en, fr, or it) and tenantEmail on Flatfox. Without them the link contains the word undefined in their place.

The link is present on every response that was processed, including a skipped duplicate. It is absent when the request is rejected before processing, for example for a wrong key or an unknown organization. Only use it when result is success.

Incomplete data becomes a draft

Where other systems reject a payload with missing or invalid fields, Evorest accepts the Flatfox payload and keeps what it can. The deposit is created as an incomplete draft, the invalid values are left empty, and the property manager gets an email to complete it in the property-manager app. The answer is success. Evorest does not send the draft to the tenant. Send complete data anyway: the property manager has to repair a draft by hand.

Other differences in the inbound call:

• allowInvestment is not fixed. Omit it to leave investment allowed.
• If the main tenant’s previous address has no reliable country, Evorest may fill tenantAddressCountryCode from the street, postal code, and city. Send the country when you have it.
• Several organizations can share one x-external-org-id. Evorest then picks the organization by the domain of propertyManagerEmail, so send it. If no organization matches, the request is rejected.
• Some organizations only accept deposits whose propertyManagerEmail domain matches the organization’s. Others are skipped with the reason Property manager email domain mismatch.

Documents Evorest sends

Flatfox does not use the file part the other integrations use. Each document is a multipart POST with:

Part	Meaning
document	The PDF. Not present for aborted.
external_contract_id	The deposit’s external id.
document_type	bank_confirmation for the pay-in confirmation, payment_slip for the QR slip, or aborted when the deposit is withdrawn.
iban	The deposit account IBAN. On aborted the field is only present because the endpoint requires it. It does not identify an account, so ignore it.

The pay-in confirmation and the payment slip go to different paths on your side. The withdrawal (aborted) goes to the same path as the payment slip, so tell the types apart by document_type.

Headers are x-api-key and a Flatfox user agent. There is no x-external-org-id. Evorest configures the target URL per organization. Delivery and retries are described in Document callback. Flatfox receives no pay-out file.