Developer docs

Apps for every member, and the facts worked out. Every member of an organization that connected an app signs in to it, on that connection, and a Cypress Manager signs in to a Cypress app for one customer. Offers and closings come with the date math and the ranking done (answerOrder, urgency), vehicles gain comparable sales, damage lines, estimate_value and read_import_file, accounts say their kind and limits (account), and Huddle's conversations have their own scopes. See the 1.9.0 notes on each page and the API reference's Changes in 1.9.0.

Your inventory, kept in step. A push can carry the link of a Manheim condition report (inspectionReportUrl): Cypress reads its grade, damages and photos; floorPrice sets the floor and a saved location's name fills its address. And removeMissing=true makes a bulk push your whole inventory: the vehicles it leaves out are taken off, with their status in the answer and in the VEHICLES.DISPOSITION.* events. See Pushing inventory. Archiving changed for every door: Cypress reviews a seller's archive only when the vehicle has an open offer or a sale in progress; otherwise it is archived at once (see De-listing). Two fixes: a re-push without condition keeps a grade an inspection set, and the report endpoints are documented as what they are.

Apps and agents. Connect Cypress lets an organization's admin approve an app (OAuth 2.1 with PKCE); an MCP client needs no registration with Cypress, signing in with a client ID metadata document or registering itself (RFC 7591). Its tokens act for that admin or for the agents the app adds: members with the Agent role, recorded under their own names. Three MCP servers: Cypress Operate, Cypress Intelligence, and the public Cypress Manual; Operate shows an agent its 13 core tools and reaches every other operation through discovery. Some decisions are a person's whoever asks and answer 403 PEOPLE_ONLY, nothing written: accepting or countering below the floor from any caller, and from an agent setting the floor, approving a quarter, confirming money arrived or sending a campaign (the list). GET /api/v1/members and /api/v1/connections list your people, agents and connected apps.

The whole desk. Offers, CRM, tasks, Mission Control, insights, notifications, closings, marketing and your organization's own automations (with GET /api/v1/automation/manifest, the node catalog), each with a pair of scopes (:read, :write). Every write takes ?dryRun=true (every rule checked, nothing written: { "dryRun": true, "changes": … }, with changes: null and a note when nothing would change) and an Idempotency-Key: offers, listings, the CRM, tasks, Mission Control, closings, marketing and automations, and the older writes too (vehicles, their costs, odometer readings, ownership, sold-elsewhere and departures, Planning's blockers and moves, Buy planning's targets, purchases and quarters, notification preferences). The Sell plan gains its strategy, goals, the quarter and its approval, and Sequoia's schedule; the Buy plan, Sequoia's draft of a quarter. A goal keeps its kind (409 KIND_CHANGE).

Your own ids, in bulk, in a sandbox. Vehicles, listings, contacts, companies, deals and tasks take externalIds and are found with ?externalId=source:id (Your own ids); an id already on another record is 409 EXTERNAL_ID_TAKEN. Contacts, companies, tasks and listings upsert a hundred at a time (/bulk). A sandbox organization to build against, with offers and a closing in it, that resets itself under the same key (POST /api/v1/sandbox/reset).

Events. Every record and every Cypress-dialect event carries links.app, where it opens in the app. New opt-in families: TASK.*, NOTIFICATION.CREATED, the closing deadlines and requests (CLOSING.STEP.DUE, CLOSING.STEP.OVERDUE, CLOSING.DOCUMENT.REQUESTED), marketing (CAMPAIGN.*, CONTACT.UNSUBSCRIBED), AUTOMATION.*, the CRM (CONTACT.CREATED, CONTACT.UPDATED, BUSINESS.*, DEAL.*, OUTREACH.*), INSIGHT.CREATED, and the plans' goals, approvals and buy targets (PLAN.GOAL.SET, PLAN.QUARTER.APPROVED, BUY.TARGET.CREATED, BUY.TARGET.DUE, BUY.QUARTER.APPROVED). The Cypress envelope gains a cursor: catch up with GET /api/v1/events, deliver again with POST /api/v1/webhooks/subscriptions/{id}/replay, and narrow a subscription to some records with entityIds. See Webhooks. The lists of vehicles, listings, offers, closings and tasks take updatedAfter, as the CRM's do, to backfill a copy of your records (Events and sync).

For agent platforms. The core operations as their own OpenAPI document, in 3.1 and in 3.0 for importers that read no later version (/api/public/openapi-core.json, /api/public/openapi-core-3.0.json); Cypress's workflows as Agent Skills on the Manual; /llms.txt. See Connecting from.

What an existing key can notice. A listing price change under a live offer or a sale answers 409 CONFLICT, a buy-now below the floor 403 BELOW_FLOOR, and a buy-now on a vehicle with no floor 422 INVALID: on PATCH /api/v1/listings/{id}, on each item of PATCH /api/v1/listings/bulk, and on the compat offering POST. All of these used to be written. See Pricing & listing rules. A subscription without an event filter receives none of the new families, and an existing key holds none of the new scopes until an admin adds them; the Cypress envelope and records gain fields (links, cursor), and no field was removed or renamed.

Buy planning over the API. With Buy planning switched on (a switch of its own) and a buy-planning:write key, your purchasing system reads and sets the quarter's goal, budget and mandate, adds and edits targets, reads their live matches (a listing's public facts only, never a seller), records purchases made elsewhere, and approves the quarter — the same rules the app uses. GET /api/v1/organization gains products.buyPlanning and the capabilities buy-planning.read and buy-planning.write; a Buy route on an organization without Buy planning answers 403 BUY_PLANNING_NOT_ENABLED. The scope labels now read by side (Sell planning, Buy planning); the scope strings are unchanged, so existing keys are too. Details in the Planning API (Buy planning).

Buy planning webhooks. Three events tell your purchasing system when the plan moves: BUY.TARGET.MATCHED (a live listing fits an open target for the first time), BUY.TARGET.FILLED (a target has nothing left to buy) and BUY.TARGET.ENDED (a target's quarter closed with units short). They are opt-in, Cypress dialect only, need buy-planning:read to subscribe, and are sent only while Buy planning is on. A subscription without an event filter does not receive them, and each is delivered to an endpoint once. See Webhooks.

The closed quarter, in the contract. A quarter whose last day has passed is history, and its plan no longer changes, in the app or here. The new code QUARTER_CLOSED (409) answers a move into a window of such a quarter, a move to OPERATION or a park of a vehicle scheduled in one, a track change of a planned vehicle in one, and the hand-off of one of its windows. The request is refused whole, nothing is written, and the body gains details.vehicleIds (the vehicles it blocks, so you can send the rest again) and details.quarter. Every window of GET /api/v1/planning/plan now carries quarter and closed: read closed, not state, to know which windows take writes. What an existing key can notice: those requests used to be accepted (a move into a window, or a hand-off, answered 409 WINDOW_CLOSED only when the window itself had closed, which is now answered only in a quarter still in progress), and reasoning and plan.note no longer carry a plan version number. A vehicle already in Sell can still change track, and blockers and demotions are not refused. Details in Closed quarters and Errors.

OFFERS.ACCEPTED for every accepted offer. The webhook now follows the app's "Offer accepted" for every deal, not only the ones a seller accepts by hand or a rule accepts on arrival: it is also sent when a buyer accepts the seller's counter and when a price change a Cypress manager approved accepts an offer that now qualifies. An endpoint that listens for it (or has no event filter) receives those events where it received none before. No field was added to any event. See Webhooks.

Planning over the API. With Planning switched on and a planning:write key, push vehicles straight into Operation or Planning (lifeStage: OPERATION / PLANNING, with purchase & financing), keep them current — details, ownership, odometer readings, cost events, departures — read the plan, and drive it: sale windows, the bench, tracks, parking, blockers, and the hand-off to Sell (preview, then confirm). Every write is one plan version; a busy plan answers 409 PLAN_BUSY with Retry-After. PLAN.* webhooks are opt-in and Cypress-dialect only, and so are VEHICLES.* events about planning stock. What an existing key can notice: a PATCH on planning stock without planning:write now answers 403 SCOPE_MISSING (was 409 PLANNING_STOCK); /vehicles/{id}/ownership reads and replaces a Sell vehicle's purchase & financing with just the vehicles scope; and a Manheim-compatible bulk unit whose embedded offering names an ungranted channel is now refused (422 CHANNEL_NOT_GRANTED) instead of created without it. Details in the Planning API and Errors.

GET /api/v1/organization — what your organization and key may do, with a reason for every refusal. Refusals across the API now carry a stable code: ORG_NOT_ACTIVE, SCOPE_MISSING, PLANNING_NOT_ENABLED and CHANNEL_NOT_GRANTED join PLANNING_STOCK and LIFE_STAGE_READ_ONLY. Keys can now hold planning:read/planning:write scopes, letting you list and read planning stock (?lifeStage=OPERATION,PLANNING) on an organization with Planning. Two deliberate changes for existing keys: planning stock at an organization without Planning now answers 403 PLANNING_NOT_ENABLED instead of 409 PLANNING_STOCK, and a vehicles-only key pushing a vehicle/unit with an embedded listing/ offering now answers 403 SCOPE_MISSING for the listings scope instead of creating it. Everything else is unchanged for vehicles you push and sell today. Details in Your organization and key, Vehicle lifecycle and Errors.

Every vehicle now carries lifeStage — where it is in its life with the fleet. The API works on Sell stock: vehicles a fleet keeps in Operation or Planning are hidden, and Sell actions on them answer 409 PLANNING_STOCK. Nothing changes for vehicles you push and sell today. Details in Vehicle lifecycle and Errors.

The Cypress API (/api/v1) is the canonical surface — resource nouns, PATCH semantics, bulk to 500. The Manheim-compatible dialect (/api/compatible/v1) mirrors Manheim's Units/Offerings/Subscribers conventions for teams with existing client code. A vehicle pushed through either is fully manageable through both.