Commonly used methods

OData

Some of our methods support OData query params:

  • $inlinecount (can retrieve total count even though not all elements are fetched by $top)
  • Read some notes about this function in the best practice section.
  • $skip (skip X number of elements)
  • $top (get X number of elements)
  • If not specified, set to 100
  • $select (select column/attribute X, Y, Z)
  • If not specified, fetches all possible fields that are set/valid on the property
  • $filter (filter on column/attribute X, Y, Z)

Example from AdvancedPropertySearch:

flow/api/Search/AdvancedPropertySearch?$inlinecount=allpages&$skip=0&$top=10&$select=Id,Address,Office,BidAcceptedDate,Municipality,BrokerName,CaseReferralKey,AssignmentType,CaseCategoryType,Status&$filter=Id eq 10

Get national identification number for person

Retrieves the last 5 digits of the national identification number for a person (personnummer)

GET /flow/api/Persons/{id}/FullIdentityNumber

QueryParam
Id: int
Response
String

Get contacts system ids based on case role

Retrieve the contacts ids that have specific role on a case

GET /flow/api/Cases/{id}/Roles/{type}/Ids
  • Id: int - CaseId for the case you want to get contacts for
  • Type: CaseRoleType

There are many types, but the most common are:
Broker, Buyer, Seller, Stakeholder, Assignee, BuyerAssignee

Response
List<int>

Add notification

Send a notification either on mail, sms or as a client notification (Core notification)

POST /flow/api/Notifications

Request Body

  • Importance = “Medium”
  • SourceType = “CaseBase”
  • CaseId: int
  • NotifyDateTime: DateTimeOffset - When is the user going to get the notification
  • Subject: string - Title for email or client notification (not in use for sms)
  • Description: string - Message that is sent
  • IsDescriptionHtml: bool
  • ContactIds: List - List of contact ids that should receive the notification
  • CustomRecipients: List - List of recipients that should receive notification
    • Email addresses
    • Phone numbers
  • SendEmail: bool
  • SendSms: bool
  • SendToClient: bool - This will send a notification in Core to the specific employee
    Response
    Model containing the info you just sent

Get Publications on a Case

Retrieves all publications on a given case. Supports OData

GET /flow/api/Cases/{id}/Publications?returnOnlyExisting=false
  • Id: int
  • returnOnlyExisting: bool

Creates new publication if it does not exist.
Notable fields to filter on are:

  • ProviderName: Publication provider name (String)
  • Status: Publication status (Enum)
  • PublishSeparately: Used to publish projectunits separately (bool)

Get Metadata for roles on a Case

This gives additional context to the role a contact has on a case. With OData support, you can get all contacts with a specific role, such as only Owners, Sellers, all roles a contact has on a case and more depending on what you would like to filter on.

GET /flow/api/Cases/{caseId}/Roles

Response
List<CaseRoleModel>
Response returned does not give specific information about the contact. This must be requested separately by using the ContactId.

GET /flow/api/Cases/{caseId}/Roles?$filter=Type eq 'Seller' or Type eq 'Owner' or Type eq 'Spouse' or Type eq 'Assignee'

GET /flow/api/Cases/{caseId}/Roles?$filter=Type eq 'Buyer' or Type eq 'OriginalBuyer' or Type eq 'BuyerAssignee'

Is the contact deceased?

Core does not have information about this on an individual level, and is only available for cases in which this has been specified.

GET /flow/api/Cases/{caseId}/Roles?$filter=Type eq 'Owner'&$select=IsDeceased

Getting recently Modified Cases

Whenever specific changes are made to a case, we track this by adding a timestamp to the changed field.

The following endpoint, supplied with a filter can then be used to find all cases modified in a given timeframe:

GET /flow/api/Integrations/RecentlyModified/Cases

This endpoint is additionally throttled to max 6 times per 30 seconds.

Response
List<RecentlyModifiedCase>

Returns a list of CaseId and f.ex. CaseSoldDate, which you will then compare to your supplied date to determine what type of change has been performed, and whether or not you should retrieve new data from that Case.

Get all employees 

flow/api/Employees?$filter={any object available in response}

Response
EmployeeModel

Get main image of case 

GET /flow/api/Cases/{caseId}/Image/{ImageSize}

ImageSize: Original, Thumbnail, Small, Medium, Large, ThumbnailSquare, SmallSquare

Response
filedata content-type: image/jpeg

Get Brokers profile image 

GET /flow/api/PropertyTypes/{id}/Images/{size}

Case prospect

Retrieving a case prospect

Model definitions

RecentlyModifiedCase

  • ModifiedDate: DateTimeOffset - Last modified date for this item.
  • CaseActivatedDate: DateTimeOffset? - Date when the case was activated
  • CaseSoldDate: DateTimeOffset? - Date when the case was set to sold
  • BidChangedDate: DateTimeOffset? - Last time a bid was added to this case
  • DescriptionChangedDate: DateTimeOffset? - Date when description of the case was changed, - includes fields such as CommonCondition, Building, SaleInformation
  • CaseEntityChangedDate: DateTimeOffset? - Date when a new contact is added to this case
  • ImageChangedDate: DateTimeOffset? - Last time an image file were added or deleted
  • AttachmentChangedDate: DateTimeOffset? - Date attachment file is changed - attachment file being the files inside the attachment system folder
  • TransactionChangedDate: DateTimeOffset? - Date when transaction is changed (Useful for bookkeeping)
  • PublicationChangedDate: DateTimeOffset? - Date publication was last changed
  • ActivityChangedDate: DateTimeOffset? - Date when activity was changed last time
  • CaseId: int - Unique identifier for the case.

PublicationStatus

  • NotPublished
  • Published
  • PublishFailed
  • Removed
  • RemovalFailed
  • Paused
  • PublishUpdateFailed

Create Stakeholders

Stakeholders must have a processing basis to be contactable. When creating a stakeholder there are two options for selecting the processing basis.

Option one is to get a list of processing bases, select the ones you want to and send their guids back in the create stakeholder request:

Requirements

  • Valid Flow API ClientId and -secret
  • API read access to Processing Bases

Steps to implement

1. Get a list of valid processing basis

All active processing bases can be retrieved by calling the following method:

GET api/ProcessingBases/Newest

If you know the category and type you can use the category-specific method:

GET api/ProcessingBases/{processingBasisCategoryType}

Here is an example for getting a list of showing and manual consents for a specific property:

GET api/ProcessingBases/SpecificCase?displayTypes=Showing&displayTypes=Manual

2. Post information to the public integrator endpoint

When you have one or more processing basis GUIDs plus all relevant information for the person you are registering you can call the following method to create the stakeholder:

POST api/Public/Cases/{guid}/Stakeholders

The URL must contain the correct GUID for the property you are registering a stakeholder on. The body must contain the following fields to be accepted by the API:

  1. FirstName
  2. SurName
  3. Email -or- Telephone
  • Note that a valid country prefix should be specified, or the system will assume a Norwegian telephone number and add +47. Supported country telephone number prefixes can be retrieved using the method GET api/Customer/Addresses/Country
  1. CheckedProcessingBases (from step 1)

Here is an example of a valid POST request body for the Stakeholder endpoint:

api/Public/Cases/680f1e7f-90e4-472d-8991-a9d6043df603/Stakeholders

{
  "FirstName": "Brus",
  "SurName": "Li",
  "Email": "brus.li@jeetkune.do",
  "Telephone": "+4799999999",
  "CheckedProcessingBases": ["cff34c62-014a-4cf2-b285-88ca73381b1d"]
}

Option two is to set ProcessingBasisCategory and ProcessingBasisSystemType in the create stakeholder request. This option can only be used if you only need to add one processing basis for the created stakeholder:

POST api/Public/Cases/680f1e7f-90e4-472d-8991-a9d6043df603/Stakeholders

{
  "FirstName": "Brus",
  "SurName": "Li",
  "Email": "brus.li@jeetkune.do",
  "Telephone": "+4799999999",
  "ProcessingBasisCategory": "SpecificCase",
  "ProcessingBasisSystemType": "Manual"
}

Possible values for ProcessingBasisCategory:

Standalone = 0, // Frittstående (urelatert)
SpecificCase = 1, // Gjelder en spesifikk eiendom
SimilarCases = 2, // Gjelder lignende eiendommer
Lead = 100, // Er relatert til et lead
BankLead = 999 // Er relatert til et banktips

Possible values for ProcessingBasisSystemType:

/// <summary>
/// Manually set processing basis (i.e not system triggered)
/// </summary>
Manual = 0,
/// <summary>
/// Automatically set by system when a seller role is assigned
/// </summary>
IsSeller = 10,
/// <summary>
/// Automatically set by system when a buyer role is assigned
/// </summary>
IsBuyer = 11,
/// <summary>
/// Automatically set by system when a stakeholder role is assigned
/// </summary>
IsStakeholder = 12,
/// <summary>
/// Automatically set by system when a bidder role is assigned
/// </summary>
IsBidder = 13,
/// <summary>
/// Automatically set by system when a support case role is assigned
/// </summary>
/// <remarks>See EntityBaseHelper.cs for list of support roles.</remarks>
IsSupportRole = 20,
/// <summary>
/// Automatically set by system when an other (minor) role is assigned
/// </summary>
/// <remarks>See EntityBaseHelper.cs for list of main and support roles.</remarks>
IsOtherRole = 21,
/// <summary>
/// A basic premisson for registration of users in customerweb
/// </summary>
CustomerRegistration = 30,
/// <summary>
/// Used to make the user contactable in regards to newsletters and other updates regarding the property market
/// </summary>
NewsLetter = 60,
/// <summary>
/// Checklist related processing basis (can be linked to checklist item)
/// </summary>
Checklist = 100

Both options can be combined, so you can select some processing bases manually and add another by setting ProcessingBasisCategory and ProcessingBasisSystemType.

Get User Data

This endpoint fetches information about the logged-in user using the provided Bearer token. It returns some useful information for integrators, mainly TenantId for the customer base and a list of the user’s Permissions.

GET api/User