Document callback

For integrations that accept files, Evorest POSTs PDFs to a URL on your server. You tell Evorest the base URL and one path per document type when the integration is set up. They are not part of the open-deposit request, and Evorest only sends the document types you have a path for.

Which partner receives what

System	Payment slip	Pay-in confirmation	Pay-out confirmation	Withdrawal	Insurance documents
Propbase	Yes	Yes	Yes	No	Yes
Emonitor	Yes	Yes	Yes	No	No
Custom	No	Yes	Yes	No	No
Flatfox	Yes	Yes	No	Yes, without a file	No
Woonig	No	No	No	No	No

365immo receives status changes as JSON, not PDFs. GaraioREM v2 receives its documents as messages.

When Evorest sends

Document	When
Payment slip	The bank has opened the deposit account and Evorest has created the QR payment slip. The PDF is the slip, with the IBAN to pay into.
Pay-in confirmation	The deposit has become open: the full amount is paid in. The PDF is the bank’s credit advice. If the tenant paid in several instalments, Evorest sends the earlier credit advices too, each in its own call. Sent once per deposit.
Pay-out confirmation	The deposit is being closed and the bank’s account-closing statement is available. Each statement is its own call.
Withdrawal	The property manager withdrew the deposit before it was paid in.

Deposits that were opened with the insurance product have no bank account, so they never produce a payment slip, pay-in, or pay-out file.

Delivery

• The request is multipart/form-data over HTTPS. Any HTTP 2xx answer counts as received. Any other status, or no answer within 30 seconds, counts as a failure. Redirects are followed.
• After a failure Evorest tries again straight away, up to ten attempts in total, with a delay that doubles from 0.1 seconds and never exceeds one second.
• Pay-out files are tried again on the next regular check until they are accepted, so the same file can arrive more than once. Make your endpoint idempotent: use x-external-contract-id together with the file name to spot a repeat.
• A payment slip or pay-in file that fails all ten attempts is not queued for a later automatic resend. If your endpoint was down, ask Evorest to send it again. See Getting access and support.
• When one event has several files, for example several credit advices, the calls are made in parallel. Do not rely on their order.

Propbase and Emonitor

Headers:

Header	Meaning
x-api-key	The same organization key you use to call Evorest.
x-external-org-id	The external organization id.
x-external-contract-id	externalContractId, so you can match the file.

The body is multipart/form-data.

Document	Parts
Pay-in confirmation	file, the PDF.
Pay-out confirmation	file, the PDF.
Payment slip	file, the PDF, and metadata, a JSON part (application/json) with { "iban": "<iban>" }.

Propbase also receives the insurance documents, when the organization offers insurance and you have given a path for them:

Document	Parts
Insurance opening	file, the PDF.
Insurance activation	file, the PDF, and metadata with { "insurancePolicyId": "<id>" }. The id is empty if the insurer has not issued one.

Custom

Authentication on this callback is HTTP Basic, not x-api-key. Headers:

Header	Meaning
Authorization	Basic <base64 username:password>, agreed at setup.
x-external-org-id	The external organization id.
x-external-contract-id	externalContractId.
x-is-closing	false on a pay-in confirmation, true on a pay-out confirmation.

The only multipart part is file, the PDF. There is no payment slip for Custom.

Which path Evorest uses decides the type as well: pay-in and pay-out go to two different paths. x-is-closing repeats it.

Flatfox

Flatfox uses different part names and sends no x-external-org-id. See Flatfox.

Testing

Tell Evorest which paths you have built and ask for sample callbacks for your test deposit. See Getting access and support.