FieldproxyFieldproxy
Get Demo
FieldproxyAI-native field service software

Reporting and data

How do I build a custom dashboard or app on top of my field service data with an API?

First find out how your field service software lets data out: a REST or GraphQL API, a reporting API, scheduled exports, or a sync to a database you own. Then point a BI tool (Power BI, Looker Studio, Metabase) or an app builder (Retool, Softr) at that source, either by calling the API on a schedule or, more reliably, by copying the records into your own database and building on that. The limits that decide whether it works are set by the vendor, not the dashboard tool: which plan includes API access, how often you may call it, and whether every field you need, such as job status, parts and technician, comes back.

  • Check API access by plan first: Housecall Pro's API and webhooks need its MAX plan; ServiceTitan customer-built apps need The Works or Enterprise Plus.
  • Rate limits shape the design: ServiceTitan allows 1 run of the same report per minute per tenant on its reporting APIs.
  • Power BI on a Pro licence refreshes a scheduled dataset up to 8 times a day, so it is not a live board.
  • Copy records into a database you control for BI; call the API live only for small, action screens.
  • Store the vendor's record ID on every row so the dashboard can link back to the job.
Fieldproxy

This page is about building on top of field service data. If the dashboard you need is a standard one (jobs by status, revenue by technician), check the built-in reports before you build anything.

Facts checked as of November 2026. Sources at the end of the page.

Step by step

How to build a dashboard or app on field service data, step by step

The same six steps apply whether the result is a Power BI report for the owner or a small app for project managers.

1. Write down the questions the screen must answer

Name the decisions, not the charts: which jobs are waiting on parts, which jobs are ready to schedule this week, which sites are past their PM date, what each project manager owes the customer. Each question tells you the tables and fields you need, for example jobs.status, jobs.assigned_pm, parts on order and the due date.

2. Find every way data leaves your FSM

Most vendors offer some mix of a REST or GraphQL API, a reporting API that runs saved reports, outbound webhooks, CSV export and built-in integrations. Jobber's Developer Center lets you build an app on its GraphQL API, including a custom integration for just one account. ServiceM8's REST API takes an API key in the X-API-Key header. Housecall Pro generates admin-only keys with full or read-only access.

3. Check the plan, the policy and the limits

Housecall Pro says its API is available only on the MAX plan, and webhooks too. ServiceTitan says customer-built apps need The Works or Enterprise Plus and that third parties may not use your App Key. ServiceTitan's default limits are 60 calls per second per application per tenant on regular APIs and 1 run of the same report per minute per tenant on reporting APIs.

4. Pick live calls or a copy

Live calls suit a small action screen that shows one project manager's open jobs. A copy suits anything with history, totals or joins: a scheduled job pulls changed records into a database you own (Postgres, SQL Server, a warehouse) and webhooks top it up between runs. BI tools then read the database, which is faster and does not spend your API allowance.

5. Build the screen in a BI tool or an app builder

Power BI can call a web API through Power Query's Web.Contents, which accepts custom headers and a request body. Looker Studio and Metabase connect to PostgreSQL. Retool connects to any REST or GraphQL API with custom headers, and Softr can build apps on PostgreSQL or any REST API.

6. Decide who maintains it and how people act on it

Name an owner for every query and key. Keys expire and get revoked: Housecall Pro warns that deleting a key breaks any integration using it. Then decide what happens when someone sees a problem on the dashboard. If they must open the FSM to fix it, add a link from each row to the job.

What we hear

Why it goes wrong

These are the problems field service buyers described to us on sales calls, by trade and size.

The data you need was never captured as data

A commercial electrical contractor serving self-storage sites wanted project managers to open one screen of parts needed and jobs ready to schedule. In its current tool those states lived in tags people had to add by hand, so a dashboard would only be as good as the tagging. If a status is not a field, no API can report it.

The export is locked

A plumbing and HVAC company could not export its price book from the add-on it used, and an architectural lighting installer said its old tools passed payments but not job-level data. Before building, test that the API returns every field your questions need, not only customers and invoices.

Spreadsheet macros became the reporting system

A risk inspection services firm exported spreadsheets and ran them through macros each cycle. It works until a column moves or the export changes, and nobody else can maintain it. A scheduled copy into a database removes the manual export.

The in-house build stalls

A structural engineering inspection firm was weighing an in-house build, and a nationwide furniture installation network said building its own tooling took time. A dashboard is days of work; a custom app that writes back to jobs, handles logins and survives vendor API changes is a product someone has to own.

The refresh is slower than the work

Dispatch and parts decisions change by the hour. On a Pro licence Power BI allows 8 scheduled refreshes a day on shared capacity, and refreshes there must finish within two hours. A board that is three hours old is fine for the owner's weekly review and wrong for dispatch.

Customers need to see it too

A display installation campaign company asked for a client view-only role on its dashboard and live map. Before building, check how outside viewers will log in and that each one sees only their own sites.

Options

Ways to build on field service data

What each route gives you, as of November 2026. Check the vendor's current docs before you commit.

RouteWhat it looks likeWatch for
Built-in reports in your FSMMost FSMs ship reports and dashboards. Microsoft lists analytics for reporting on key performance indicators as part of Dynamics 365 Field Service.You get the vendor's fields and layouts. Custom views across jobs, parts and project managers are often out of reach.
BI tool calling the FSM's APIPower BI's Web.Contents with an API key header, on a refresh schedule. ServiceTitan's reporting APIs return saved report data; Jobber's GraphQL API returns what you query.Power BI says POST requests with Web.Contents can only be made anonymously, so the key goes in a header. Reporting limits (1 run of the same report per minute on ServiceTitan) slow large refreshes.
Copy into your own database, then BIA scheduled sync plus webhooks keeps a Postgres or SQL Server copy current. Metabase (open source) or Looker Studio read it directly.Someone owns the sync code and the schema. Looker Studio's PostgreSQL connector caps a query at 150K rows and may time out after three to five minutes.
Internal app builder on the APIRetool or Softr screens that read the FSM's REST API and can write back, for example a project manager screen with a Mark parts arrived button.Writes through someone else's API must follow its rules, and each user of the app needs access to the builder.
FSM where screens and data are open (Fieldproxy is one)In Fieldproxy each workspace has its own Postgres database, read-only SQL over MCP, a REST API, and screens that are JSON you can change, so the dashboard can live inside the same app the team uses.You still need to decide the questions and fields first. Very large warehouses still belong in a dedicated BI stack.

Vendors are named for what their public docs say. Being listed here does not mean a route covers your workflow.

Worked example

A worked example: a project manager board for parts and scheduling

Say a commercial electrical contractor has 30 technicians and 6 project managers, with about 400 open jobs at any time. Each project manager wants one screen: their jobs waiting on parts, jobs whose parts have arrived and are ready to schedule, and jobs past their due date.

Route one: Power BI calling the FSM's API. On a Pro licence the report refreshes up to 8 times a day. Spread across a 10-hour working day, that is a refresh about every 75 minutes, so a part that arrives at 9:05 may not show as ready to schedule until after 10:15. If the FSM's reporting API allows 1 run of the same report per minute, and each project manager's view is the same report with a different filter, refreshing all six takes at least six minutes.

Route two: copy and query. A sync job pulls changed jobs every 15 minutes into a Postgres table and a webhook updates a job the moment its status changes. A Metabase dashboard filtered by project manager reads that table. 400 open jobs is a small query, so each page loads in a second and the data is minutes old, not hours.

Route three: an app that acts. The project manager clicks Parts arrived on a row and the job moves to Ready to schedule in the FSM. That needs write access through the API, not only read, and someone to own the app. In every route the real dependency is the same: parts needed and ready to schedule must be fields or statuses on the job, set by the people doing the work.

Before you buy

What to check before you buy or build

Good signs

  • API access is included on the plan you will buy, in writing.
  • The API returns every field your questions need, including custom fields, statuses and line items.
  • There is a way to read data by query (joins, date ranges, totals), not only one record at a time.
  • Webhooks fire on job status changes so a copy can stay current between scheduled pulls.
  • Keys can be read-only, limited to some tables and set to expire.
  • A sandbox or test account exists so you can build before you go live.

Red flags

  • API access only on the top plan, or third-party access restricted by policy.
  • Reporting limited to saved reports you cannot change, with tight per-minute limits.
  • Key states such as waiting on parts exist only as free-text notes or tags.
  • Exports that leave out the price book, line items or photos.
  • No answer to who maintains the queries when the vendor changes its API.

In Fieldproxy

Setting it up in Fieldproxy

Fieldproxy is built to be open, so a dashboard can sit inside the app your team already uses or outside it in your own BI tool.

Make the states real fields first

Jobs use your own stages, statuses and fields, so waiting on parts and ready to schedule are statuses (e.g. waiting_parts, ready_to_schedule) and the project manager is a field on the job, not a tag someone remembers to add.

Query it with read-only SQL

Each workspace runs on its own Postgres database. Through the MCP server, describe_schema lists every table and column you may read, run_sql runs one SELECT (up to 500 rows, 5-second limit) and export_csv saves up to 10,000 rows. Command Center dashboards are built from tiles, each one read-only SELECT. See /mcp.

Build the screen inside Fieldproxy

Every web and mobile screen is JSON: views, widgets and the SQL behind them, with charts, tables, maps, kanban and calendars. A project manager board can be one view with a Parts arrived button that updates the job, versioned with drafts, publish and rollback. Portal users can sign in and see only their own records, enforced by Postgres row security.

Or feed your own BI tool

The REST API (POST /api/read, /api/insert, /api/update, /api/delete with an x-api-key) reads by exact match and returns every column. The db_sync automation step copies records to an external database in batches, on a schedule or as they change, for Power BI, Looker Studio or Metabase to read. Keys are created in Settings, Security, API keys, one per system, with an expiry, operations and optionally only some tables.

Send it on a schedule and try it first

The Scheduler agent emails reports and briefings on a schedule, such as a Monday list of jobs waiting on parts per project manager. A public read-only sandbox workspace with sample data lets you test the API and SQL before you sign anything. API access is included on every plan; pricing is one price per company with unlimited users, see /pricing.

How switching works

How switching to Fieldproxy works

We move your data over and set the system up to the way you already work. Fieldproxy replaces the old tool; it does not run alongside it.

  1. Bring the questions and the spreadsheets

    Show us the reports you build by hand today and the decisions they drive. We list the fields and statuses each one needs.

  2. We set up the fields and the first dashboard

    We add the statuses and fields to jobs, move your data over and build the first board as a Fieldproxy screen, so your team sees it in the app they already use.

  3. Connect your BI tool if you want one

    We create a read-only API key limited to the tables your BI tool needs, or set up a db_sync to your own database, and check the numbers match for a week.
Fieldproxy developers: REST API, MCP, webhooks, apps as JSONGet your Fieldproxy data into BI or a warehouseTry the read-only sandboxPricing: one price per company, unlimited users

FAQ

Questions people ask

Can I connect Power BI to my field service software?
Usually, through the vendor's API with Power Query's Web.Contents, or by copying the data into a database Power BI reads. On a Pro licence a scheduled dataset refreshes up to 8 times a day, so use it for reviews, not live dispatch.
Can I build my own reports and dashboards and still use the API for third-party BI tools?
That depends on the vendor's plan and policy. Housecall Pro's API needs its MAX plan, and ServiceTitan limits customer-built apps to The Works or Enterprise Plus. Ask for the plan and the rate limits in writing before you build.
Should my dashboard call the API live or use a copy of the data?
Use a copy for anything with history, totals or joins, kept current by a scheduled sync plus webhooks. Call the API live only for small screens that show or change a handful of records.
Is it cheaper to build our own field service app in-house?
A dashboard on an existing API is days of work. A full app with logins, offline mobile use, scheduling and invoicing is a product that needs a team to maintain it, so most companies build only the screens their FSM lacks.
Can customers see a view-only dashboard?
Yes, if the tool supports outside users with row-level filtering. In Fieldproxy, portal users sign in and see only their own records; in a BI tool, check the licensing for external viewers.
What if the data I need is not in the API?
Then no dashboard can show it. Ask the vendor whether the field can be exposed, export it on a schedule if possible, or move to a system where the field exists and can be read.
Can AI answers be saved to a dashboard?
In Fieldproxy, yes. Command Center dashboards are built from tiles, each one read-only SELECT, and an AI assistant connected through the MCP server can propose a new dashboard or tile for a person to publish.

Sources

Competitor details on this page come from the vendors' own pages and documentation, checked as of November 2026. Plans and prices change, so check the vendor's current page before you decide.

Related

Keep reading

See it built on your workflow

Tell us how your jobs run today. We build a demo on your stages, forms and pricing before the call.

Get DemoGet Demo