Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

This is a brief description of the API calls most commonly used by brokers. For full details about the request and response payloads, se the swagger documentation.

Create settlement

A settlement is created by the broker to provide information to the bank and to create a channel where all parties can communicate and share documents.

The settlement contains information about what is being sold, who is buying and selling, and a set of key declarations from the broke. These declarations has a direct impact on what flow to use for the given sale. See more about declarations below.

Resource

Settlement

Service

[POST] /v1/settlements

Request

Request

Response

SettlementResponse

Code register

A list of declarations that can be included while building a Settlement resource to ensure that correct flow is set on the settlement.

Resource

Code register

Service

[GET] /v1/coderegister/brokerdeclarationtemplates

Response

BrokerDeclarationTemplateResource

List of available declarations

List of available broker declarations can be found here: Broker declarations This is used by the broker to communicate facts with potential banks.

See the below list of criterion (in Norwegian) that can be declared by the broker upon creating a settlement.

Criteria

Description

Minst en av partene må signere på papir.

Vilkår for elektronisk tinglysing er at alle parter som skal signere dokumentene kan signere med BankID (selger, kjøper, bortfester, rettighetshaver). Dersom minst en av partene må signere på papir må det svares Ja på spørsmålet.

Minst en bank må levere pantedokument på papir.

Vilkår for elektronisk tinglysing er at alle involverte banker kan levere digitalt pantedokument til megler. Dersom minst en av bankene må levere pantedokumentet på papir må det svares Ja på spørsmålet.

Overdragelsen inneholder andre avtaler som skal tinglyses.

Dersom andre avtaler skal tinglyses sammen med overdragelsen (pkt.6 i papirskjøtet) må overdragelsen opprettes på papir. Eksempel på andre avtaler kan være vegrett, forkjøpsrett, borett o.l. Årsaken er begrensninger i Kartverkets tinglysningssystem.

Overdragelsen krever vedlegg.

Dersom tinglysing av overdragelsen krever at det medfølger vedlegg må skjøtet opprettes på papir. Vedlegg kan være kjøpekontrakt, fullmakt, firmaattest o.l. Årsaken er begrensninger i Kartverkets tinglysningssystem.

Overdragelsen gjelder salg fra andre enn hjemmelshaver.

Dersom selger i overdragelsen ikke har grunnbokshjemmel, og hjemmelshaver samtykker til tinglysing, må skjøtet tinglyses på papir. Eksempel kan være ved salg av nybygg hvor utbygger ikke er tinglyst som hjemmelshaver til eiendommen. I slike overdragelser er utbygger oppført som selger, og hjemmelshaver signerer/samtykker til tinglysing på skjøtet. Årsaken er begrensninger i Kartverkets tinglysningssystem.

Overdragelsen gjelder arveoppgjør.

Tinglysing av overdragelse i forbindelse med arveoppgjør (hjemmelserklæring og skifteattest) er ikke tilgjengelig for elektronisk tinglysing. Årsaken er begrensninger i Kartverkets tinglysningssystem.

Overdragelsen inneholder sletting av festekontrakt.

Dersom overdragelsen inneholder frikjøp av festegrunn og sletting av festekontrakten, må overdragelsen tinglyses på papir. Årsaken er begrensninger i Kartverkets tinglysningssystem.

Overdragelsen gjelder etablering av borett iht. brl § 2-13.

Dersom det inngås avtale med utbygger om borett iht. brl § 2-13 må overdragelsen tinglyses på papir. Årsaken er begrensninger i Kartverkets tinglysningssystem.

Get document

When a mortgage document is uploaded to a settlement by the bank, it can be retrieved using its unique identifier (found in the SettlementResource response object).

Resource

Document

Service

[GET] /v1/documents/{uid}

Response

DocumentResponse

Monitoring settlements

The Event resource provides a rich functionality for monitoring the portfolio of settlements for a broker. It provides a list of recent events with good filtering possibilities. Events can be found by querying with either a timestamp, eventid or settlementId. If your search returns 500 records (max records returned), use ‘fromEventId’ to get the more records in a new request. This is much easier than iterating over all “open” settlements to detect changes.

Event types

To see a list of event types follow this link: swagger documentation.

Querying for all events

Resource

Event

Service

[GET] /v1/events

Response

PagedResources<EventResource>

Querying with filtering

To get only new events since the last check, use either the last retrieved eventid or a timestamp as query parameter.

Resource

Event

Service

[GET] /v1/events?fromeventid=<last_id>

Service

[GET] /v1/events?fromeventcreated=<last_checked>

Response

PagedResources<EventResource>

For a full list of filtering and sorting options, check the swagger documentation.

Validate flow

This service can be used to validate if this property can be part of a settlement with electronic flow. To see a list of rules that are applied, please follow this link: Validate flow rules

Resource

Validate-flow

Service

[GET] /v1/flowvalidations/{propertykey}

Response

PingResponse

Monitoring the service

As a client, you might be interested if the service is fully operational.

The ping resource will tell you the details about the status of the system.

Resource

Ping

Service

[GET] /v1/ping

Response

PingResponse

  • No labels