Where is the URBLD OpenAPI specification?
The full OpenAPI 3.1.0 spec is published at https://urbld.live/openapi.json. It documents 14+ endpoints across Leads, Customers, Scheduling, Estimates, Contracts, Jobs, Invoices, Payments, Follow-Ups, Communications, and Jarvis, plus complete request/response schemas and OAuth 2.0 security requirements.
The reference below is generated live from /openapi.json. For request/response schemas, error codes, and example payloads, download the spec and open it in Swagger UI, Redoc, Postman, or your OpenAPI tool of choice.
What the URBLD API covers
The URBLD API exposes the full lead-to-payment lifecycle of a service business as a single REST surface. Every endpoint is versioned under /v1, returns JSON, and is authenticated with OAuth 2.0. There is no separate admin API and no hidden internal surface — the same endpoints power the URBLD web app, the mobile app, Jarvis, and every third-party agent that connects.
Endpoints are grouped by domain and each domain maps cleanly to a workspace inside the product:
- Leads — inbound capture, deduplication, qualification, and lifecycle transitions.
- Customers — the sacred-ID customer record shared across every job and invoice.
- Scheduling — availability, appointment booking, dispatch, and route-optimizer results.
- Estimates & Contracts — line items, calculator output, e-signature packages, and revisions.
- Jobs — the operational record of work in progress: crew, materials, warranty, vault attachments.
- Invoices, Payments, Receivables — the closed-ledger financial pipeline with QuickBooks-safe sync.
- Follow-Ups & Communications — outbound SMS/email, threaded conversation history, and PNS recovery tasks.
- Jarvis — grounded manager queries that return real tool-backed answers, never hallucinated metrics.
Authentication and scopes
Every request carries an OAuth 2.0 bearer token minted for exactly one organization. Server-to-server integrations use the client_credentials grant; user-consented integrations (Zapier, ChatGPT connectors, homegrown agents acting on a user's behalf) use authorization_code with PKCE. Tokens carry a scope stack — for example leads.read scheduling.write communications.write — and the API enforces the smallest privilege model: an agent scoped to leads.read cannot read jobs, and no token can ever cross the organization boundary. Full details live in the Authentication guide.
Rate limits, errors, and audit
The default rate limit is 120 requests per minute per organization with a burst of 300; higher-tier plans get proportionally higher budgets. On 429 Too Many Requests the response includes a Retry-After header — respect it and back off exponentially. Error responses follow a stable shape with error.code, error.message, and error.details. Every mutation writes an entry to the tenant's audit log with the resolved actor identity, the scope stack that authorized the call, and before/after state — so owners can trace exactly what any agent did, when, and why.
Discovery documents
In addition to the OpenAPI spec, URBLD publishes a full set of machine-readable discovery documents so a modern agent framework can auto-configure without a human writing glue code: /.well-known/ai-capabilities.json for capability metadata, /agent.json for integration profile and contact details, and /llms.txt for LLM crawlers. Point a compliant framework at urbld.live and it will find everything it needs.
Endpoints
Loading specification…
Frequently Asked Questions
Straight answers about how URBLD runs the business end-to-end.