Deal Dates

How it works

Written for the people who have to approve it: what is read, what is stored, how it authenticates, and where it runs. Everything on this page describes the system as it exists, not as planned.

What it is

A daily email to each agent listing the deadlines on their open reZEN transactions — condition dates, firm dates, closings, and dates recorded only in the file's comments — with any required checklist documents still outstanding and what changed since the day before. Conditions that a filed waiver notice or an amendment has dealt with are dropped from the list. Team leads receive their own deals in full plus a short exceptions summary for the deals they oversee.

In production In daily use since August 2026; the home page shows the live delivery record, computed from what was actually sent. Vendor onboarding with Real Brokerage for Sign in with reZEN is in progress.

What it reads

Agent identity	`/agents/me` — the key holder, and whether they lead a team
Team roster	`/teams/{id}` — member ids and email addresses, so the digest can be addressed. Nothing is typed in by hand.
Open transactions	`/transactions/participant/{id}/transactions/OPEN`, then each transaction's detail for dates, side, clients and the co-operating agent
Checklist	`/checklists/{id}` — which required documents are outstanding, and whether a condition waiver notice has been filed
Documents	The purchase contract, its amendments and the waiver notice, each read once for the typed terms and for which conditions were waived
Activity and comments	The transaction's change log and comment thread, for the “since yesterday” section and the `Terms:` / `Dates:` comment conventions. This is reZEN's Platform permission.

Every request is a read. The product contains no code path that writes to reZEN — it cannot create, edit or terminate a transaction, alter a checklist, or touch commissions. Only the OPEN transaction set is requested; closed and terminated deals are never fetched.

What it never reads

Any account other than the key holder's own, or their team where reZEN already grants them that visibility.
Commission amounts, rev-share, cap or income data. The key it needs does not include those scopes, and the code does not request them.
Document contents, with one exception: the purchase contract, its amendments and the waiver notice, each read once on our own server — for the typed “Other terms”, and for which conditions were removed or waived. The file itself is not kept; the few typed sentences and the list of waived conditions it yields are, so the document is never read twice. Every other checklist item is read for its status only, never the file.

Authentication

Sign in with reZEN is the primary model. A team lead signs in to reZEN and approves a consent screen once; Real issues Deal Dates a credential that acts as that lead, limited to the permissions approved — read-only, four of them: Transaction, Document, Team, Account. Nothing is written, ever. The credential lives twelve hours and is renewed automatically from a rotating refresh token; nobody generates, copies or emails anything.

A fifth read permission, Platform, covers the transaction's change log and comments — the “since yesterday” section. Sign in with reZEN does not offer it yet; we have asked Real for it. Until then a team connected this way receives every date, document and term, but no “since yesterday”. An API key can carry Platform today.

That makes read-only a property of the credential rather than a promise about the software: even a defective or compromised build could not alter a transaction.

The lead can disconnect from their settings page (which revokes the credential at Real within seconds, at most fifteen minutes) or revoke the application from reZEN itself. Either takes effect without anything from us. The consent is remembered by reZEN, so reconnecting later is a redirect, not a second approval.

An agent's own reZEN API key still works as an alternative — read-only, the same four permissions plus Platform, and nothing else: no Global access, no Rev Share, Cap, Income or Reference, and never Write — for a team that prefers it.

Where the credential goes. The sign-in finishes on this website, which is the only place the exchange can happen — the one-time code Real issues lives sixty seconds. The credential is immediately encrypted to a key held only on the digest server, handed over sealed, and forgotten. It never rests here in the clear, and the settings page never displays it.

What is stored

Per team	Open transactions as last fetched — address, dates, side, status, client name, co-operating agent — the checklist items that determine condition status, the dates found in comments, and what each contract, amendment or waiver notice yielded when it was read
Per recipient	Which local date a digest was last sent, so no day is sent twice; their delivery preferences (send hour, timezone, how far ahead, opted out or not); and the private token behind their calendar feed if they use one. No digest content is kept.
Isolation	Each customer's data lives in its own database schema. One customer's rows are not reachable from another's connection.
The credential	The reZEN grant (or an API key) is held separately from the deal data, in the customer's own schema, never written to a config file, log, or email, and never shown on the settings page.
Retention	Refreshed daily to reflect what is open. Deleted within 30 days of a customer leaving; sooner on request.

Delivery

Once a day, at 6am in the recipient's own timezone — derived from where each agent is licensed, and overridable per person. A team spread across provinces gets each member's digest in their own morning.
If the sending host was unavailable at 6am it delivers when it returns rather than skipping the day, and never sends the same day twice.
Nothing is sent when there is nothing to say. A daily "no deadlines today" trains people to stop reading.
An optional mid-day notice, off unless a person turns it on: at noon on a day when a closing or a condition they chose is due on one of their deals, one short email naming it and the other agent. Conditions already waived are left out, and there is never more than one a day.
Every digest states that it is a reminder and not the source of truth, and that deadlines should be confirmed against the contract.
Every digest carries a one-click unsubscribe (the kind Gmail and Outlook show in the header) and a link to a settings page where each person sets their own send time, timezone, how far ahead it looks and which days it comes. A team lead can do the same for anyone on the team, and add an assistant or transaction coordinator as a recipient.

Where it runs

The digest server	Reads reZEN, holds the data and the credential as above, and composes the email. A server in Canada operated by us.
Email	Sent through Resend from an authenticated sending domain — SPF, DKIM and DMARC — so it cannot be spoofed and reliably reaches the inbox.
Cloudflare	This website, the settings page, the sign-in handoff and the calendar feed. Holds names, email addresses and delivery preferences — never a deal, never a credential in readable form.

Status and scale

One team in daily production since August 2026, now joined by a small private beta of Real Broker teams, onboarded by hand and one at a time. It is deliberately not self-serve yet: a tool that states contract deadlines has to be right before it is big.

Questions

Technical or data-handling questions to privacy@dealdates.app; anything else to hello@dealdates.app. The plain-language version of the data section is at Privacy & data.