Getmomo Public API (1.24.0)

Retrieves all deposit accounts with pagination support

Retrieves a single deposit account by its unique identifier

Retrieves all virtual deposit accounts associated with a specific deposit account with pagination support

Consistency

This list serves a background-rebuilt read model. A freshly created account can be missing, a freshly deleted one can still appear, and a freshly updated one can show its previous field values. See the Consistency section in the API description.

Creates a new virtual deposit account for individual tenant(s) or company tenant. Use the 'type' field to specify which type to create.

Consistency

The response body carries the created account and its version tokens. An immediate GET of the new account can return 404 and an immediate list can omit it. See the Consistency section in the API description.

Interrupted requests

The creation is a durable multi-step operation. Once the request has passed the checks above, it completes even if the connection drops or the service restarts before the response is sent. In that case you receive a transport error or a gateway error, and the account is still created, possibly a few minutes later. An interrupted creation resumes where it stopped and yields exactly one account, with or without a sourceId. Treat such an error as an unknown outcome and retry the request with the same sourceId. A 409 DUPLICATE_SOURCE_ID on the retry confirms the earlier creation. A 201 means the retry performed it. A retry is a new creation and only the sourceId deduplicates it against the interrupted one, so send one whenever the creation must happen exactly once.

Retrieves a single virtual deposit account by its unique identifier

Consistency

This endpoint serves a background-rebuilt read model. Right after a create it can return 404, right after a delete it can still return 200, and right after an update it can return the pre-update fields and the pre-update version tokens. See the Consistency section in the API description.

Deletes a single virtual deposit account by its unique identifier. The deletion is rejected with a 409 response when the virtual deposit account holds any booked transactions. Deletion requires the current version of the virtual deposit account for optimistic concurrency, so that stale writes are detected. The get virtual deposit account endpoint returns that version. After a write of your own to this account, take the version from that write's response body instead.

Consistency

Once this operation returns 204 the account is deleted. An immediate GET can still return 200 and an immediate list can still include it. See the Consistency section in the API description.

Interrupted requests

The deletion is a durable multi-step operation. Once the request has passed the checks above, it completes even if the connection drops or the service restarts before the response is sent. In that case you receive a transport error or a gateway error, and the account is still deleted, possibly a few minutes later. Treat such an error as an unknown outcome and retry the request. A 404 NOT_FOUND on the retry confirms the earlier deletion. A 204 means the retry performed it.

Partially updates a virtual deposit account together with its rental contract, tenants and company directors in one call. Only the fields you send change; anything omitted is left as-is. At least one mutable field beyond version and rentalContractVersion must be present, otherwise the request is rejected with 400 BAD_REQUEST / REQUEST_VALIDATION_FAILED.

Optimistic locking

Every call must carry the current top-level version and rentalContractVersion. Each tenant slot you mutate must carry that tenant's current version. A stale value is rejected with 409 CONFLICT and nothing is written: errorCode is VERSION_CONFLICT or TENANT_VERSION_CONFLICT, and for TENANT_VERSION_CONFLICT details also carries tenantIndex. The response returns the freshly incremented versions of the entities that changed; unchanged entities keep their previous version.

Updating tenants (positional)

tenants[i] addresses the i-th stored tenant. The array never reorders existing tenants, but a non-null slot at a position beyond the current tenants creates a new tenant (omit version on a creating slot).

• Omit tenants entirely to leave all tenants unchanged.
• An empty slot {} (or a slot carrying only its version) leaves that position unchanged. Use it to skip earlier tenants when you only want to change a later one:

{
  "version": "3",
  "rentalContractVersion": "5",
  "tenants": [
    {},
    { "version": "7", "lastName": "Neu" }
  ]
}

• A shorter array leaves the trailing tenants unchanged.
• null at a position removes that tenant. Removing a non-trailing tenant compacts the list: survivors keep their relative order and are renumbered 0..n-1. The last remaining tenant cannot be removed; the request is rejected.

{
  "version": "3",
  "rentalContractVersion": "5",
  "tenants": [
    {},
    null
  ]
}

• A non-null slot at a position beyond the current tenants creates a new tenant. A creating slot omits version and must include firstName and lastName. Creation applies to individual accounts only, up to 5 tenants; a company account always has exactly one company tenant and cannot gain more.

{
  "version": "3",
  "rentalContractVersion": "5",
  "tenants": [
    {},
    { "firstName": "Neu", "lastName": "Mieter", "dateOfBirth": "1990-05-05" }
  ]
}

Company directors (positional)

Inside a company slot, companyDirectors fully replaces the stored directors by position. Omit the key to leave directors unchanged. A shorter array removes the trailing directors; a longer one appends. The array must hold 1 to 3 directors, so you cannot clear every director.

Property owner (tri-state)

Omit propertyOwnerId to leave it unchanged, send null to detach the current owner, or send an id to attach an owner. An id that does not belong to you is rejected with 409 CONFLICT / PROPERTY_OWNER_NOT_FOUND.

Clearing text fields

Omit notes / payoutNote to leave them unchanged, or send null to clear them.

Consistency

The response body carries the new state and the current version tokens. An immediate GET of the account can return every mutable field at its pre-update value, and the tokens it returns can be the pre-update ones. Feed the next write from this response body, not from that GET. The top-level version mirrors the deposit and is not changed by this operation. rentalContractVersion and the tenant versions do change. See the Consistency section in the API description.

Interrupted requests

The update is a durable multi-step operation. Once the request has passed the checks above, it completes even if the connection drops or the service restarts before the response is sent. In that case you receive a transport error or a gateway error, and the update is still applied, possibly a few minutes later. Treat such an error as an unknown outcome and retry the request with the same body and the same version tokens. A 409 CONFLICT with errorCode VERSION_CONFLICT or TENANT_VERSION_CONFLICT on the retry confirms the earlier update; read the current state and tokens with a GET (see Consistency above, it can lag). A 200 means the retry performed it.

Consistency

An immediate GET of the virtual deposit account can still return the pre-payout status. This operation converges later than the other writes, because the read model updates when the outgoing transfer is submitted to the bank rather than on this request. The stale window is observable on a partially funded account. On a fully funded account the recomputed status is the same value. See the Consistency section in the API description.

Consistency

This operation changes the account's status. An immediate GET can still return the pre-payout status. See the Consistency section in the API description.

Interrupted requests

The payout is a durable multi-step operation. Once the request has passed the checks above, it completes even if the connection drops or the service restarts before the response is sent. In that case you receive a transport error or a gateway error, and the payout is still requested, possibly a few minutes later. Treat such an error as an unknown outcome and retry the request with the same idempotency key. A 409 CONFLICT with errorCode PAYOUT_ALREADY_REQUESTED on the retry confirms the earlier request. A 202 means the retry performed it.

Retrieves the current balance of a virtual deposit account

Consistency

This endpoint is strongly consistent. It reads the ledger directly, not the read model behind the other reads, so it reflects a write as soon as the write returns.

Initiates the asynchronous generation of a tax certificate for a virtual deposit account and the requested tax year. Returns the created async job, which can be polled via the get async job endpoint and whose artifact can be downloaded once completed.

Initiates the asynchronous generation of an all-time bank statement (Kontoauszug) for a virtual deposit account. Returns the created async job, which can be polled via the get async job endpoint and whose artifact can be downloaded once completed.

Retrieves the current state of an asynchronous job (e.g. tax certificate or bank statement generation) initiated for the authenticated manager.

Mints a fresh short-lived presigned HTTP-GET URL (TTL 7 days) for the completed job's artifact in partner-facing object storage; returns a new URL on every call.

Retrieves all property owners with pagination support

Consistency

This list serves a background-rebuilt read model. A freshly created property owner can be missing and a freshly updated one can show its previous field values. See the Consistency section in the API description.

Creates a property owner scoped to the authenticated manager

Consistency

The response body carries the created property owner and its version. An immediate GET of it can return 404 and an immediate list can omit it. See the Consistency section in the API description.

Retrieves a single property owner by its unique identifier

Consistency

This endpoint serves a background-rebuilt read model. Right after a create it can return 404, and right after an update it can return the pre-update fields and the pre-update version. See the Consistency section in the API description.

Updates a property owner scoped to the authenticated manager. Only the fields present in the request body are changed; omitted fields are left unchanged and an explicit null clears a nullable field. The supplied version must match the property owner's current version.

Consistency

This operation increments the version and returns the new one in the response body. Use that value for your next write. An immediate GET can return every mutable field at its pre-update value together with the pre-update version, and sending that version back produces 409 CONFLICT / PROPERTY_OWNER_VERSION_CONFLICT with no concurrent writer involved. See the Consistency section in the API description.