EverReal
  • Introduction
  • Authentication
    • API ClientID and ClientSecret
    • Authentication limitations
  • Rate limiting
  • Helpers
    • Errors
    • Pagination
    • Formatting
  • How to guide
    • EverReal Data Import Process
      • Connect an Integration
      • Import Mappers
      • Ideal CSV Structure
      • Debug Imports
      • FAQ
    • Data import via GraphQL
  • Endpoints
    • Account users / members
    • Owners
      • Owners Query
      • Owners Mutation
    • Property Groups
      • Property Groups Query
      • Property Group Mutation
    • Properties
      • Properties Query
      • Properties Mutation
    • Units
      • Units Query
      • Units Mutation
    • Listing
      • Listing Query
      • Listing Mutation
    • Candidates
      • Candidates Query
      • Candidate Mutation
    • Messages
    • Contact Activites
    • Tenants
      • Tenants Query
      • Tenant Mutation
    • Contract
      • Contract Query
      • Contract Mutation
    • Contacts
      • Contact Mutation
      • Contact Query
    • Document management
      • Document management
      • Simple file upload
    • Tasks
      • Tasks Query
    • Protocols
      • Protocol Query
  • Webhooks
    • Owner Events
      • OWNER_CREATED
      • OWNER_UPDATED
      • OWNER_DELETED
    • Property Events
      • PROPERTY_CREATED
      • PROPERTY_UPDATED
      • PROPERTY_DELETED
    • Unit Events
      • UNIT_CREATED
      • UNIT_UPDATED
      • UNIT_DELETED
    • Listing Events
      • LISTING_ACTIVATED
      • LISTING_ARCHIVED
      • LISTING_UPDATED
      • LISTING_DEACTIVATED
      • LISTING_CREATED
      • LISTING_PUBLISHED_TO_CHANNEL
      • LISTING_UNPUBLISHED_FROM_CHANNEL
    • Candidates Events
      • CANDIDATE_PARSED
      • LISTING_CANDIDATE_APPLIED
    • Listing Contracting Events
      • LISTING_CONTRACT_FLOW_SIGNED
      • LISTING_CONTRACT_FLOW_PARTIALLY_SIGNED
      • LISTING_CONTRACT_FLOW_WITHDRAWN
      • LISTING_CONTRACT_FLOW_STARTED
    • Listing Scheduling Events
      • LISTING_CANDIDATE_SCHEDULE_TIMESLOT_BOOKING_REMOVED_CANDIDATE
      • LISTING_CANDIDATE_SCHEDULE_TIMESLOT_BOOKING_REMOVED_ADMIN
      • LISTING_CANDIDATE_SCHEDULE_TIMESLOT_BOOKED_CANDIDATE
      • LISTING_CANDIDATE_SCHEDULE_TIMESLOT_BOOKED_ADMIN
      • LISTING_CANDIDATE_SCHEDULE_NEW_TIMESLOTS_REQUESTED
      • LISTING_CANDIDATE_SCHEDULE_INVITED_VIEWING
    • Protocol Events
      • PROTOCOL_COMPLETED
  • Change log
    • Releases
      • Introducing Mappers
      • Enhancements for GraphQL
      • Enhancements for Querying
      • Enhancements for Webhooks
    • Upcoming
      • Introduced Querying Protocol in GraphQL
Powered by GitBook
On this page

Was this helpful?

  1. How to guide
  2. EverReal Data Import Process

FAQ

Which system is the Single Source of Truth? To avoid discrepancies and allow consistent data depending on what's the core business of the partners software there needs to be on Single Source of Truth. For e.g. if there is being integrated an ERP system with EverReal the SSoT is the ERP system.

With what frequency will the data be transferred? How often will data be imported should be clarified already from the beginning. The recommended frequency is once a day for data which is not changing that often as for e.g. terminations of contracts.

A real time synchronisation of master data won't be supported. In case there is a valid reason a real time synchronisation should be considered EverReal should have a detailed overview provided with it.

Does the integration aim to be bi-directional? For bi-directional integrations there should be a documentation what possibilities are provided by the partners software. This should be clear before the integration start.

Is a detailed description of goals & time plan available?

A detailed description of the integration goals should be provided to EverReal after deciding on the integration type (API or CSV files) with all the required fields.

PreviousDebug ImportsNextData import via GraphQL

Last updated 2 years ago

Was this helpful?