Fieldproxy developer docs

Your own systems read and write the workspace's data over HTTPS: POST /api/read, /api/insert (plus CSV import), /api/update and /api/delete on the workspace's regional API base. Writes fire the workspace's automations. Auth: An API key in the x-api-key header, created in Settings, Security, API keys: one per system, with an expiry, the operations it may use and optionally only some tables. Revocable.

An official Model Context Protocol server over HTTP at https://<api-host>/mcp (for example https://api-india-1.fieldproxy.ai/mcp), with 170+ built-in tools. Claude, ChatGPT, Microsoft 365 Copilot and Teams (through Copilot Studio), GitHub Copilot, Cursor, OpenAI Codex, Claude Code and any other MCP client can read the workspace, run read-only SQL, propose changes, draft messages, run automations and build apps. Auth: OAuth sign-in (the token lasts 1 hour and renews itself for 30 days) or a scoped key (fpmcp.…) sent as Authorization: Bearer.

describe_schema lists every table and column the connection may read; run_sql runs one SELECT against the workspace's own Postgres database (up to 500 rows, 5-second limit). export_csv saves up to 10,000 rows as a CSV link. Auth: The MCP connection's data:read scope. Hidden columns are removed and row limits are applied by Postgres.

In: an automation with a webhook trigger gets its own URL; any system POSTs JSON to it and the steps read {{trigger.body.field}}. Out: http_request (any method, headers, JSON or file body), send_webhook (HMAC-SHA256 signed), call_integration and db_sync, plus send_email, send_sms and place_call. Auth: In: no sign-in, an optional shared secret in the x-automation-secret header, and the rule must be on. Out: credentials from the encrypted secret vault as {{secrets.NAME}}, never written into the rule.

Rules are JSON: a trigger (15 types, from record events and cron to SLA timers, zones and GPS arrival) and a list of steps (about 50 types). Create, validate, dry-run, enable, run, retry and restore versions. Auth: From the MCP server (save_automation, simulate_automation…) or the automation API with a signed-in administrator session.

Open forms anyone can fill in, record links for one customer's quote, job or invoice (with signatures and Stripe payments), no-login customer portals, and lookup pages. Links can expire, be capped and be revoked. Auth: Built and published through the public-forms API by a signed-in administrator; the people filling them in need no login.

Customers, contractors and partners sign in with their own email and password to one web app and see only their own records, enforced by Postgres row security. Auth: Set up by an administrator in Settings, Portal users, then invited.

Every screen of the web and mobile apps is JSON: views, widgets, actions and the SQL behind them. Read, edit, validate, render, publish and roll back versions through MCP. Auth: The MCP build scope (an administrator, with Allow build switched on).

Phone agents and SMS or email agents that answer customers from live data, configured as JSON with instructions, allowed tables, tools, hours and a knowledge base, and tested in a simulator. Auth: The MCP build scope, or the agent settings in the web app.

Import CSV or Excel into any table (up to 1,000 rows per MCP import, dry-run first), and export CSV or Excel from any screen or query. Auth: In the app, or the MCP data:write and data:read scopes.

Read, insert, update and delete workspace data over HTTPS with an x-api-key: per-system keys with an expiry, operation scopes and an optional table allowlist. REST writes fire automations.

How AI clients and integrations sign in to Fieldproxy: OAuth sign-in or fpmcp keys made in Settings, AI assistant, with scopes, row and column limits, expiry and revoke.

Every built-in tool on Fieldproxy's MCP server, grouped by area, with what each does and which scope it needs.

How field service data is stored in Fieldproxy: a Postgres database per workspace with customers, locations, jobs, technicians, quotes, invoices and your own tables.

Fieldproxy automation rules: trigger types including inbound webhooks, and step types including outbound HTTP requests, email, SMS and phone calls.

Open forms, record links, customer portals and lookup pages that people outside the company use without a login, and how they are published and linked.

Every Fieldproxy screen is JSON: views, widgets, actions and SQL, rendered on web and mobile, versioned with drafts, publish and rollback.

Fieldproxy's phone, SMS and email AI agents: configuration, tools, the confirm gate, the simulator and conversation logs.

Read-only SQL limits, propose-confirm-undo, bulk limits, send limits, approvals, sandboxes and audit logging on Fieldproxy's API surfaces.