generated: '2026-07-26'
method: searched
source: >-
  The 35,698-character info.description published inside the DDF Web API documentation at
  https://ddfapi-docs.realtor.ca/ (harvested to openapi/realtor-ca-ddf-web-api-docs-openapi.json),
  cross-derived against the operation parameters in both harvested OpenAPI documents
docs: https://ddfapi-docs.realtor.ca/#section/OData
protocol:
  style: OData v4 (RESO Web API shape)
  transport: HTTPS only, minimum TLS 1.2
  response_format: JSON for all resources; XML for the $metadata document
  base_urls:
    web_api: https://ddfapi.realtor.ca/odata/v1
    lead_api: https://ddfapi.realtor.ca/v1
    analytics: https://analytics.crea.ca/LogEvents.svc
authentication:
  style: OAuth 2.0 client_credentials -> Bearer token
  header: 'Authorization: Bearer {access_token}'
  token_url: https://identity.crea.ca/connect/token
  token_lifetime_seconds: 3600
  sliding: false
  detail: authentication/realtor-ca-authentication.yml
idempotency:
  supported: false
  note: >-
    No idempotency contract. The DDF surface has exactly one write operation
    (POST /v1/Lead/CreateLead) and it accepts no idempotency key, request-id or dedup token — the
    strings "idempoten" and "Idempotency-Key" do not appear anywhere in the documentation or in
    either harvested OpenAPI. The only dedup behaviour published anywhere in the estate is on the
    fire-and-forget analytics service, which ignores duplicate events from the same UUID within a
    5-minute window; that is server-side event dedup, not request idempotency.
  analytics_dedup_window: 5 minutes (same UUID)
pagination:
  style: OData server-driven paging with nextLink, over $top/$skip
  default_page_size: 20
  max_page_size: 100
  params: [$top, $skip, $orderby, $count]
  response_fields:
    next: '@odata.nextLink'
    context: '@odata.context'
    items: value
  example_next: https://ddfapi.realtor.ca/odata/v1/Member?$top=20&$skip=20
  total_count:
    param: $count
    guidance: >-
      CREA warns $count carries a performance cost and should be requested once, not on every
      page.
  ceiling:
    records: 10000
    guidance: >-
      "If you wish to paginate through more than 10,000 listings you will need to use the
      dedicated replication endpoint."
  ordering_warning: >-
    Results are unordered unless $orderby is supplied; CREA warns that without sorting, multiple
    pages may return the same record more than once.
query:
  select: $select — choose which properties to return
  filter: $filter — boolean filter expression
  orderby: $orderby
  top: $top
  skip: $skip
  count: $count
  operators: [eq, ne, gt, lt, ge, le, and, or, not, in, has]
  functions:
  - name: any
    note: >-
      Matches any element of a collection/complex type, e.g.
      $filter=Heating/any(a: a eq 'Electric')
  - name: contains
    note: >-
      Substring filtering on string fields for Property, Office and Member, added August 1st 2025.
      String fields only — lookup fields must be filtered with the lookup values from $metadata.
  expansion:
    supported: false
    note: >-
      No $expand. Media, Rooms and SocialMedia are returned as inline collections on the parent
      resource rather than as separately expandable navigation properties, and there is no
      standalone RESO Media resource.
incremental_sync:
  mechanism: polling
  endpoints:
  - /odata/v1/Property/PropertyReplication()
  - /odata/v1/Member/MemberReplication()
  - /odata/v1/Office/OfficeReplication()
  per_destination_form: '{Resource}Replication(DestinationId={DestinationId})'
  cursor_field: ModificationTimestamp
  photo_cursor_field: PhotoChangeTimestamp
  guidance: >-
    Replication endpoints return records sorted by modification timestamp so an external system can
    pull only what changed since its last run. CREA's documented client guide is: initial full load,
    then repeated LastUpdated/ModificationTimestamp-filtered pulls, then a master identifier list to
    detect removals, then per-ListingKey detail fetches.
  no_webhooks: >-
    There is no push. The strings "webhook" and "Webhook" do not appear in the documentation;
    change propagation is entirely client-polled.
timestamps:
  timezone: UTC
  note: >-
    All timestamp fields on Property, Member, Office, Destination and the Replication endpoints are
    returned in UTC (release notes, 17 Aug 2023 and 22 Sep 2023), and UTC is expected when
    filtering on timestamp fields.
  precision: ModificationTimestamp precision changed to 2 decimal places (release notes, 8 Jun 2023).
metadata:
  url: https://ddfapi.realtor.ca/odata/v1/$metadata
  format: XML (OData CSDL)
  anonymous_status: 401
  note: >-
    The machine-readable OData contract — including every lookup value clients must filter on — is
    itself behind the Bearer gate. CREA documents it as "(Requires authentication)".
localization:
  cultures: [en-CA, fr-CA]
  note: >-
    Lead submissions carry a required Culture field (en-CA or fr-CA, default en-CA). CREA publishes
    guidance for encoding French and special characters in Web API request strings. API support is
    English only.
versioning:
  scheme: uri-path
  current: v1
  detail: lifecycle/realtor-ca-lifecycle.yml
errors:
  envelope: >-
    Non-200 responses return a JSON error object. The OData surface wraps it as
    {"error":{"message":..,"code":..,"details":..}}; the Lead API returns a flat
    {"success":bool,"message":..,"code":..,"details":..} body.
  rfc9457: false
  content_type: application/json
  catalog: errors/realtor-ca-problem-types.yml
rate_limits:
  documented: false
  note: >-
    None published. "rate limit", "throttle" and "quota" do not appear in the documentation, and no
    X-RateLimit / Retry-After header is documented. The only stated ceilings are structural: 100
    records per page, 10,000 records before you must move to replication, and a 60-minute token
    life.
request_tracing:
  request_id_header: null
  note: No correlation/request-id header is documented or returned in the documented error envelope.
testing:
  sandbox: false
  note: >-
    There is no sandbox environment or test tenant — integrators test against live production data
    with live feed credentials. The one published test affordance is the Lead API's
    SuppressEmail=true query parameter, which runs a real lead submission without emailing the
    REALTOR: https://ddfapi.realtor.ca/v1/Lead/CreateLead?SuppressEmail=true
  recommended_client: Postman (CREA ships no collection)
display_obligations:
  attribution_required: true
  note: >-
    A cross-cutting rule that is unusual in an API contract: every DDF listing displayed on an
    external website must carry the clickable "Powered by REALTOR.ca" badge (English and French
    variants supplied), linking back to the original listing on REALTOR.ca. Real estate advertising
    websites must additionally route "Email REALTOR" form submissions through the Lead API, because
    member email addresses are deliberately withheld from the feed payloads (see MemberEmailYN).
  source: https://ddfapi-docs.realtor.ca/#section/DDF(r)-Web-API/Website-requirements