canonical: https://jentic.com/apis/nekst.com/nekst

# Nekst API

Jentic publishes the only available OpenAPI specification for Nekst API, keeping it validated and agent-ready. Nekst is a real estate transaction management platform that automates the post-contract checklist for agents and brokerages, turning repetitive closing steps into scheduled tasks, reminders, and assigned activities. The API exposes transactions, contacts, tasks, webhooks, and roles so external systems can sync deal data, read transaction status, and react to contract milestones. It is designed for real estate teams that want to integrate Nekst with their CRM, MLS feed, or document workflow.

## For AI agents

Manage real estate transactions, contacts, tasks, and roles in Nekst, and subscribe to webhooks that fire when deal milestones change.

## Scope

Does not handle MLS listings, document signing, or commission disbursement - use for real estate transaction tracking only.

## Capabilities

- Create and update real estate transactions with status, role assignments, and milestone dates
- Sync contact records between Nekst and an external CRM using the contacts endpoint
- Subscribe to webhooks that fire when a transaction status changes so agents are notified instantly
- Read and assign roles across a transaction including buyer, seller, lender, and title officer
- Pull a complete transaction history for reporting, commission calculation, or compliance review
- Verify API token validity through the auth test endpoint before running scheduled jobs

## Use cases

### Real Estate Transaction Sync

Brokerages running a separate CRM or document platform use the Nekst API to keep transaction data in lockstep. The `/v1/transactions` endpoints expose create, read, and status update operations, so a contract signed in DocuSign can spawn a Nekst transaction with the right role assignments in seconds rather than hours of manual entry.

Example prompt: Create a new transaction in Nekst with property address 123 Main St, status Under Contract, and assign roles for buyer agent and listing agent.

### Milestone Webhook Notifications

Operations teams subscribe to Nekst webhooks so downstream systems react when a transaction status flips. The `/v1/webhooks` endpoints register a callback URL, and `/v1/transactions/{id}/status` drives the events. This replaces email parsing or polling loops and lets a Slack channel or commission engine update the moment escrow closes.

Example prompt: Register a webhook pointing at https://example.com/nekst-events and verify it fires when a transaction status changes to Closed.

### Contact and Role Management

Transaction coordinators use the contacts and roles endpoints to assemble the cast for each deal - buyers, sellers, lenders, inspectors, and title agents. The API reads the role catalogue from `/v1/roles` and writes contact links via `/v1/contacts`, removing the duplicate-entry problem when a contact already exists in the firm CRM.

Example prompt: List the available roles in Nekst, then attach an existing buyer contact to transaction id 4711 with the role Buyer.

### AI Agent Integration via Jentic

An AI agent loads Nekst operations through Jentic by searching for the intent rather than reading docs. Jentic returns the matching operation schema, the agent fills in property address, role assignments, and milestone dates, and executes the call against `/v1/transactions` without ever touching the raw API token.

Example prompt: Use Jentic to search for create real estate transaction, load the schema, and create a Nekst transaction tied to a contract signed today.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | `/v1/auth/test` | Verify the API token is valid |
| GET | `/v1/transactions` | List transactions |
| GET | `/v1/transactions/{id}` | Get a single transaction |
| PUT | `/v1/transactions/{id}/status` | Update a transaction status |
| GET | `/v1/contacts` | List contacts |
| GET | `/v1/webhooks` | List registered webhooks |
| POST | `/v1/webhooks` | Register a webhook |
| GET | `/v1/roles` | List role definitions |

## Key resources

- **Transactions** — Create, read, and update real estate transactions; manage status changes
- **Contacts** — Attach and read contacts on a transaction
- **Webhooks** — Register callback URLs that fire on transaction status changes
- **Roles** — List the role catalogue used to assign people to a transaction
- **Auth** — Validate the configured API token

## Why Jentic

- **Setup:** Wiring the Nekst API by hand means passing the API token on every request, verifying it against the auth test endpoint, and mapping transactions, contacts, and roles across the app host yourself. Through Jentic you install once, import Nekst from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** Nekst puts the transaction id in the URL path (`/v1/transactions/{id}/status`), so a rule can pin your agent to one transaction: it can read that transaction and update its status and nothing else. You choose the operations it may call, so webhook creation is not included unless you add it.
- **Credential handling:** Your Nekst API token is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'update a real estate transaction status' or 'list contacts', and Jentic returns the matching Nekst operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **HubSpot CRM** — General-purpose CRM that pairs with Nekst to hold the wider contact and deal record
- **Pipedrive API** — Sales pipeline platform sometimes used by real estate teams instead of a vertical tool like Nekst
- **Salesforce** — Enterprise CRM that brokerages use for portfolio reporting alongside a vertical transaction tool

## FAQ

### Why is there no official OpenAPI spec for Nekst API?

Nekst does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call Nekst API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the Nekst API use?

The Nekst API uses an API token sent via the apiToken security scheme. Jentic stores the token encrypted in your Jentic One instance and injects it at execution time, so the token never enters the agent context. You can verify the token by calling GET `/v1/auth/test.`

### Can I subscribe to transaction status changes with the Nekst API?

Yes. Register a webhook with POST `/v1/webhooks` and point it at your callback URL. Nekst will POST to that URL when a transaction status changes, including the events surfaced by `/v1/transactions/{id}/status.`

### How do I create a real estate transaction with the Nekst API through Jentic?

Search Jentic for create real estate transaction, load the operation schema for POST `/v1/transactions`, then execute with the property and role payload. The full flow is pip install jentic, search, load, execute.

### What are the rate limits for the Nekst API?

Nekst does not document explicit per-second rate limits in the spec. Treat the API as a regular write-light, read-moderate service: cache role and contact lookups, and avoid polling `/v1/transactions` when a webhook subscription will deliver the same change events.

### Can I list all the role types available in a Nekst transaction?

Yes. Call GET `/v1/roles` to get the full catalogue of role definitions, which you then reference when attaching contacts to a transaction via `/v1/contacts.`

### Can I limit what my agent is allowed to do with the Nekst API?

Yes. Because you run Jentic One yourself, your own rules decide which Nekst operations and credentials the agent may use. Since Nekst puts the transaction id in the URL path (`/v1/transactions/{id}/status`), you can pin the agent to a single transaction so it only reads that transaction and updates its status. You choose the exact operations it may call, so actions like registering a webhook via POST `/v1/webhooks` are excluded unless you grant them.
