Your real estate tools.
One API.

Connect any HTTP-capable AI harness to shared client, property and deal records, practical workflow tools, and recurring jobs.

Create your account Complete OpenAPI schema · Harness instructions

Start with an account

Use the signup page, or present the privacy and access terms to the user and call POST /v1/accounts with {"name":"Your account label","acceptTerms":true} after acceptance. The response contains a unique account ID and an API key shown once. Keep the key in backend credential storage. Do not put it in prompts, source control, URLs, or analytics. Names are labels, not verified identities; ownership is established by key possession. No password recovery is provided.

Authenticate with Authorization: Bearer YOUR_KEY. GET /v1/account lists key IDs. POST /v1/account/keys creates another key; {"revokeCurrent":true} rotates the current one. Delete an individual key with DELETE /v1/account/keys/{id}. Keys configured by an administrator remain administrator-managed.

Connect and save context once

Create records with POST /v1/records: kinds are client, property, deal, activity and brand. Use the exact schemas in OpenAPI. Save returned IDs and supply the current version when updating a record. Each account owns its records. List by kind with pagination.

Your harness can supply source data through records and tool inputs, or connect providers through PUT /v1/connections/{provider}. This credential-management endpoint belongs in the harness backend, outside the model tool list. Connection secrets are encrypted and never returned.

ProviderCredentials and use
fubapiKey for Follow Up Boss contacts, calls, events and tasks. Sync contacts with crm.sync, then each selected client’s activity with crm.sync_activity. Follow pagination; the provider does not expose every activity.
creaclientId and clientSecret from a licensed DDF feed. property.sync checks a saved watch; optional city adds potential buyer matches. Coverage is determined by feed rights. Missing records never imply sold or withdrawn status. Results currently cap at 100 and expose truncation.
googleaccessToken, optionally refreshToken with its original OAuth clientId and clientSecret. Gmail send/read scopes support booking requests and confirmation evidence; Calendar events access supports confirmed appointments. Expired tokens without refresh credentials require reconnection.

Call a tool

GET /v1/tools returns tool input schemas. Call POST /v1/tools/{operation} with JSON and a unique Idempotency-Key header (8–120 letters, digits, underscores, periods, colons or hyphens). Reuse that key for retries of the same operation and input. The response is a durable job; inspect status and result. Only job.status=succeeded indicates that the tool ran successfully. HTTP 200 alone does not mean the business action succeeded.

POST https://homies-paperwork.vercel.app/v1/tools/crm.next_actions
Authorization: Bearer [injected by your backend]
Idempotency-Key: daily-actions-20260908
Content-Type: application/json

{"limit":10}

For explicit queueing, use POST /v1/jobs with operation and input, then POST /v1/jobs/{id}/run. Poll GET /v1/jobs/{id}. Jobs survive restarts, have leases, and retain errors. Retry a failed job after resolving its error. An uncertain email delivery is reconciled before any resend; do not create a replacement tour to bypass that protection.

Seven workflows

Watch my properties

“Keep an eye on the properties that matter to my clients.”

Resolve saved client and property records first. Ask one simple question at a time only for missing context. Use the connected licensed listing feed or ingest authenticated source snapshots. Confirm the requested watch scope and cadence, register the recurring refresh, and notify only on relevant price/status changes or new buyer matches. Include source dates and affected clients. Do not imply a listing feed is connected when it is not.

property.watch · property.refresh · property.sync

Plan my day

“Plan my day and show me who needs my attention.”

Sync connected CRM history and commitments before ranking. Use saved work hours and contact capacity; ask only if missing. Return evidence for each priority, a useful message draft, and the next action. Treat missing contact history as unknown. Record completed actions when the user reports them; send only when authorized.

crm.sync · crm.sync_activity · crm.next_actions · crm.complete_action

Track my transaction

“Help me keep this deal on track.”

Resolve the saved deal and source agreement. Extract dates, parties, conditions, obligations and required documents from source text with exact quotes and page references. Resolve relative dates and timezone explicitly; never assume an unstated deadline. Ask the user to review the extracted obligations, then activate tracking and agreed reminders. Keep unreviewed candidates separate from tracked deadlines.

transaction.extract · transaction.review · transaction.track · transaction.complete · transaction.document

Prepare my seller update

“Prepare my next seller update.”

Resolve the seller and listing from saved context. Collect showing feedback, listing engagement, marketing activity and competing listing snapshots for the reporting period from connected sources. Use the saved brand. Generate the report with source dates and missing-data disclosure. Return the artifact for review and offer a weekly schedule; send only if authorized.

seller_report.build

Organize my showing tour

“Organize and book my next showing tour.”

Resolve saved buyer preferences and property shortlist. Ask for missing availability one question at a time. Use verified travel times, confirm proposed appointment windows, submit authorized booking requests and distinguish requested from confirmed slots. Reconcile office replies, send booking requests in batches of up to three, and create calendar events only for confirmed appointments. Repeat calendar calls with a new idempotency key until calendarStatus is created, then provide the itinerary. Never describe an email request or tentative event as a confirmed showing.

showings.plan · showings.book · showings.confirm · showings.calendar · showings.status · showings.itinerary

Check this property

“Help me check this property before we move forward.”

Resolve the property. Call property.dossier_lookup for Toronto municipal zoning and permit evidence. Inspect status and retrieval coverage; resolve needs_input with the exact municipal address and never silently discard unit identifiers. Native coverage currently starts in Toronto; use independently retrieved evidence and property.dossier for other municipalities. Retrieve municipal zoning, permitted-use information, permit records, flood information and taxes where publicly available or licensed. Preserve exact source URLs, retrieval dates and limitations. Do not infer parcel-specific facts from general area guidance. Produce a branded dossier and list unavailable coverage and questions for qualified reviewers.

property.dossier_lookup · property.dossier

Launch my listing

“Get my listing ready to launch.”

Use the saved property, approved photography, brand and connected accounts. Ask only for missing essentials. Produce a feature sheet, listing site, social draft, email draft and launch checklist. Review facts and assets with the user and publish/send only within their authorization. Return working artifact and publication links with actual delivery status.

listing.launch

Complete the showing flow

Plan a tour, then call showings.book with listing-office emails and authorized:true. Send at most three office requests per call. A sent request is only requested. The harness must read the office reply, verify approval of the exact requested window, and call showings.confirm with the incoming Gmail message ID, exact quote, and confirmed:true. The API verifies sender, thread and source quote; semantic review remains the harness/user’s responsibility. Alternative windows need a new reviewed plan. Only fully confirmed tours can call showings.calendar. Calendar creation handles up to two appointments per call; repeat with a new Idempotency-Key until calendarStatus is created. Calendar IDs are deterministic to prevent duplicate events on retries. Generate a branded itinerary with showings.itinerary.

Transactions and evidence

The harness reads the agreement and submits exact-quote obligations to transaction.extract. The API also surfaces conservative ISO-date candidates from source text. Relative or ambiguous dates need interpretation and timezone review; candidates are not active deadlines. Use transaction.review to activate reviewed obligations, transaction.complete to record completion, and transaction.document to register a received document’s source. Re-review resets completion states. Tracking emits each due-soon/overdue reminder once per obligation/date/urgency.

Call property.dossier_lookup with a saved propertyId for native Toronto municipal address, zoning, exclusion, height/coverage overlay and active/cleared permit retrieval. A unique exact municipal address is required; needs_input means supply municipalAddress in City spelling without discarding unit identifiers. Inspect result.status and retrieval: partial means a source failed; no_match never proves no restrictions or permits. Lookup uses address points, not a parcel survey. Cleared permit coverage starts in 2017. Flood risk, taxes and legal permitted-use entitlement remain unavailable. Other cities return unsupported. Property.dossier also assembles independently sourced findings provided by your harness. Source labels, HTTPS links and observation times are required; missing categories remain explicitly unavailable.

Artifacts and publication

Tools return artifact IDs. GET /v1/artifacts/{id} returns structured content and a private HTML preview link valid for 15 minutes. Listing launch produces a feature sheet, listing page, social/email drafts, and a checklist. It does not post to social networks or send marketing emails. To publish reviewed content at a stable public URL, call POST /v1/artifacts/{id}/publication with {"authorized":true}. Unpublish with DELETE on the same path. Delete an artifact with DELETE /v1/artifacts/{id}. Anyone with a published URL can read it; public pages are marked noindex.

Recurring work and notifications

POST /v1/schedules accepts an operation, input, intervalMinutes (60–43,200) and a first nextRunAt in ISO UTC, plus Idempotency-Key. The hourly scheduler executes due work, so a run can lag by up to an hour. Supported operations: property.sync, crm.sync, crm.sync_activity, crm.next_actions, transaction.track and seller_report.build. Seller reporting periods roll forward each run. Read schedule status or delete a schedule to stop it.

Consume GET /v1/events?after=CURSOR from the harness to notify users of meaningful changes, completed reports and deadline reminders. This service exposes events; the harness delivers notifications in its own channel. Property-change and reminder events contain relevant evidence and client/deal IDs. Avoid notifying on routine job lifecycle events. A 410 cursor error means rebuild from current records and resume.

Limits and retention

Each account supports 2,000 shared records, 500 retained jobs, 20 schedules, 2,000 recent events, and 4 MB of workflow JSON. Delete unused artifacts and finished jobs before reaching storage limits. Source agreement text and rendered HTML count toward that limit. Deleting finished jobs also retires their idempotency keys; do not reuse those keys for external actions. Signup allows five accounts per address per UTC day. API burst protection is 300 requests per address per minute. Provider quotas and permissions also apply.

Existing form licences and BCFSA publisher acceptance still apply to paperwork. Privacy and access · Workflow-only API schema