Bounded developer access

Scoped credentials and verified receipts

OrbiLattice currently exposes a narrow workspace-admin lifecycle for read-only API credentials and signed incoming-webhook verification. Review the exact boundary before building an integration.

Open developer settings Developer access terms Sign in

This is a bounded integration surface, not a promise of a complete public API, SDK, sandbox, arbitrary webhook destination, or guaranteed delivery service.

Issue once

A workspace administrator creates a credential with one of the currently allowlisted read scopes. The plaintext value is shown only in the issuance response.

Use the exact scope

The bounded developer endpoints expose a contact count or sanitized incoming-webhook receipt metadata. Other scopes are denied.

Verify local receipts

The incoming fixture path checks a timestamp and signature before claiming its workspace-scoped idempotency key.

Revoke durably

Revocation is irreversible through the management routes. Refresh shows the fingerprint and revoked state, never the prior secret.

Current request shapes

Sanitized receipt read-back

GET /api/developer/v1/webhook-receipts?provider=developer-fixture
Authorization: Bearer <one-time-issued-key>

{
  "data": [{
    "id": "<receipt-id>",
    "provider": "developer-fixture",
    "verified": true,
    "receiptState": "accepted",
    "eventTypes": ["webhook_received"],
    "receivedAt": "<timestamp>"
  }]
}

Signed local fixture

POST /api/incoming-webhooks/developer-fixture/<workspace-id>
X-Timestamp: <unix-seconds>
X-Signature: <fixture-signature>
X-Signature-Id: <configured-fixture-secret-id>
X-Idempotency-Key: <event-id>

// The same signed event id is accepted once.
// A replay is returned as deduplicated.
// Bad signatures and stale timestamps are rejected.

Assistant connector

A workspace can be connected to an AI assistant client that speaks the Model Context Protocol, so an operator can ask their own assistant what to review today or what the verified public record says about a property. The assistant reads; it does not act.

Setup-dependent and read-only. It needs an OrbiLattice workspace and a token the operator issues in settings, and it returns only what that token's scopes allow.

Read-only by construction

Nineteen tools, none of which write. The watchlist tool returns a proposal with a confirmation link for a person to action in the app; it saves nothing. Tools are advertised to the client as read-only, so a lookup need not interrupt the operator for approval.

Scoped to one workspace by the credential

A Connected Assistant token is issued for a single workspace and carries named read scopes. There is no workspace argument on any tool, so a token cannot be pointed at another workspace. A client is shown only the tools its scopes cover.

Owner identity is excluded

Property resolution runs with owner data forced off. No owner name, mailing address, or contact detail is returned by any tool on this surface.

Every call is attributed and revocable

Calls are recorded against the token that made them. Revoking or rotating the token in workspace settings cuts the client off immediately.

Client configuration

# Codex CLI — ~/.codex/config.toml
[mcp_servers.orbilattice]
url = "https://api.orbilattice.com/api/mcp/external"
bearer_token_env_var = "ORBILATTICE_TOKEN"

# Claude Code — run once
claude mcp add --transport http orbilattice \
  https://api.orbilattice.com/api/mcp/external \
  --header "Authorization: Bearer $ORBILATTICE_TOKEN" --scope user

The exact snippet for your client, with your token filled in, is generated in workspace settings. Claude Desktop is supported through a helper, because its configuration file cannot call a remote server directly.

What it will not do

Requires an existing OrbiLattice workspace and a token the operator issues — this is not an open or public API
Read-only: no tool creates, edits, sends, or schedules anything
No owner identity or contact data, and no automated valuation or appraisal
Coverage is per jurisdiction and is reported by the tools themselves — no nationwide claim
ChatGPT connectors are not supported: they require OAuth, and this surface authenticates with a scoped token

Explicit product boundary

No claim of complete public API or CRUD coverage
No official SDK, public sandbox, marketplace, or GraphQL promise
No outbound-delivery guarantee or production SLA
No credential, signing secret, raw signature, payload, or contact PII in read-back
No provider or CRM mutation in the deterministic local webhook fixture

Need a broader integration?

Confirm the required resource and operation with the product team before depending on an unproved route or delivery behavior.Contact developer support