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 any required checklist documents still outstanding. Team leads receive their own deals in full plus a short exceptions summary for the deals they oversee.

In production The digest has been in daily use by its first team since 26 August 2026; the multi-tenant product has delivered it since 13 September. Onboarding with Real Brokerage as a vendor 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

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. It reads whether a checklist item is complete, not the file.

Authentication

Each agent or team lead generates their own reZEN API key. The recommended key is read-only, with four scopes: Transaction, Team, Account, Document. Everything else — Global, Rev Share, Cap, Income, Reference — is left unset, and Write is never granted.

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 agent can revoke the key from their own reZEN security settings at any time. Revocation takes effect immediately and requires nothing from us.

Login with reZEN. The credential layer is built behind a provider interface so that a scoped, revocable OAuth token can replace the API key without changes above it. We would prefer that model — it removes key custody entirely — and will adopt it as soon as it is available.

What is stored

Per tenant	Open transactions as last fetched — address, dates, side, status, client name, co-operating agent — and the checklist items that determine condition status
Per recipient	A record of which local date a digest was sent, for idempotence. No 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 API key	Held separately from the data, never written to a config file, log, or email.
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.
Every digest states that it is a reminder and not the source of truth, and that deadlines should be confirmed against the contract.

Where it runs

Hosted	For agents and small teams without their own infrastructure. The key is supplied to us and stored as above. Mail is sent via an authenticated sending domain.
Self-hosted	Planned for teams with their own IT. The same software runs on the customer's infrastructure; the key never leaves their possession and mail goes through their own server.

Status and scale

One team in daily production. A small private beta follows, onboarded by hand, one team 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.