FieldCamp API Authentication: fc_live API Keys and Scopes

FieldCamp API authentication uses self-serve API keys prefixed with fc_live_ that you create, scope, and rotate directly from your workspace. Each key is bound to your tenant, carries a granular set of scopes, and can be sent on every request as either an Authorization: Bearer token or the equally first-class X-Api-Key header — so your integrations only do what you intend, however your HTTP client prefers to send credentials. This guide walks dispatchers, owners, and developers through generating keys, picking scopes, signing requests, and rotating credentials before they leak. For an overview of every endpoint these keys unlock, start with the FieldCamp API reference.

How FieldCamp API keys work

Every API key is a string that starts with fc_live_ followed by a random secret. The prefix tells you the environment at a glance, and the secret half is what authenticates the request. Keys are tied to:

• A tenant — your company and branch context, set automatically when you create the key while signed in.
• A set of scopes — what the key is allowed to read or write (for example, clients:read, jobs:write, invoices:read).
• An optional expiry — short-lived keys are encouraged for partner integrations and one-off scripts.
• A last-used timestamp — visible in Settings so you can spot stale or compromised keys quickly.

Because keys carry scopes, a dispatcher building a small automation can issue a read-only key for Job management without ever touching billing data in Creating invoices.

Create a self-serve fc_live API key

Send authenticated requests

FieldCamp accepts your fc_live_ key two equally supported ways. Pick whichever fits your HTTP client and stack — both are first-class and route through the same authentication pipeline.

• Authorization: Bearer <key> — the standard OAuth-style header most SDKs send by default.
• X-Api-Key: <key> — a header-only alternative that avoids the Bearer prefix, ideal for serverless gateways, low-code platforms, and tools that don't expose the Authorization header cleanly.

# Authorization bearer (recommended for most SDKs)
curl https://api.fieldcamp.ai/api/v1/company-info \
  -H "Authorization: Bearer $FIELDCAMP_API_KEY"

# X-Api-Key header (first-class alternative)
curl https://api.fieldcamp.ai/api/v1/company-info \
  -H "X-Api-Key: $FIELDCAMP_API_KEY"

import axios from 'axios';

const fc = axios.create({
  baseURL: 'https://api.fieldcamp.ai',
  headers: {
    Authorization: `Bearer ${process.env.FIELDCAMP_API_KEY}`,
    'Content-Type': 'application/json',
  },
  timeout: 30_000,
});

const { data } = await fc.get('/api/v1/company-info');
console.log(data);

import os, requests

key = os.environ["FIELDCAMP_API_KEY"]

# Either header works — pick one
r = requests.get(
    "https://api.fieldcamp.ai/api/v1/company-info",
    headers={"X-Api-Key": key},
    timeout=30,
)
r.raise_for_status()
print(r.json())

Pick the right scopes

Scopes are namespaced as resource:action. The most common combinations match common workflows in FieldCamp's lead-to-payment workflow:

Choose between Authorization and X-Api-Key

Both headers are equally supported, but each is better suited to certain situations. Use this guide to pick:

• Pick Authorization: Bearer when you're using an off-the-shelf SDK (Axios, Requests, OkHttp), when you might also call other Bearer-token APIs from the same client, or when you want consistent observability with standard logging stacks that parse the Authorization header.
• Pick X-Api-Key when you're calling FieldCamp from a serverless platform that strips or rewrites Authorization, from a low-code tool like Zapier or Make where the Bearer prefix would need manual concatenation, or from a reverse proxy that already uses Authorization for its own gateway-level auth.

For dispatch and mobile integrations that touch the dispatch calendar, X-Api-Key is often easier because mobile networking libraries sometimes mangle the Authorization header during cellular handoffs.

Manage keys via the API

You can also script key management with the same fc_live_ credentials that have the api-keys:manage scope. The /api/v1/api-keys resource supports listing, creating, and revoking keys so you can rotate them in CI pipelines.

# List existing keys (returns metadata, never the full secret)
curl https://api.fieldcamp.ai/api/v1/api-keys \
  -H "X-Api-Key: $FIELDCAMP_ADMIN_KEY"

# Revoke a key by id
curl -X DELETE https://api.fieldcamp.ai/api/v1/api-keys/key_123 \
  -H "Authorization: Bearer $FIELDCAMP_ADMIN_KEY"

This pairs nicely with Workflow automation: trigger a scheduled rotation, store the new key in your secrets vault, and revoke the previous one once deploys complete.

Rotate, revoke, and audit

Treat each fc_live_ key like a credential, because it is. Build the habit early:

• Rotate keys at least every 90 days, and immediately if a teammate with access leaves.
• Use one key per integration so revoking one never breaks the others.
• Keep an audit trail by tagging each key with the integration name and owner.
• Pair sensitive write keys with IP allowlists in your reverse proxy.
• Review the Last used column monthly and revoke any key that hasn't been called in 60 days.

If you suspect a leak, revoke the key in the dashboard right away. New requests using that secret will return 401 Unauthorized immediately, regardless of which header carried it. See API errors for the full list of authentication responses, and use idempotency keys on retries so a replayed write never duplicates work.

Troubleshoot authentication errors

A few patterns explain almost every failing request:

• 401 Unauthorized — The key is missing, revoked, expired, or both Authorization and X-Api-Key were sent with conflicting values. Make sure there's exactly one space between Bearer and the key, and that you're only sending one credential header per request.
• 403 Forbidden — The key is valid but the requested scope is missing. The most common version of this is registering a webhook without integrations:write, or updating visits without visits:write. Re-issue the key with the right scope.
• 404 Not Found — The resource exists in a different tenant. API keys never cross tenants; check the branch you signed in with when creating the key.
• 429 Too Many Requests — You've hit rate limits; back off using the Retry-After header.

FAQs

For deeper integration questions, the API quickstart walks through making your first end-to-end call, and the changelog tracks scope and endpoint changes.

Related articles

• API reference overview
• API quickstart
• API errors and retries
• Rate limits
• Idempotency
• Webhooks
• Webhook events catalog
• API changelog
• Managing API keys
• Roles and permissions in FieldCamp
• CRM overview
• Job management complete guide
• FieldCamp workflow from lead to payment
• Workflow automation overview
• Analytics overview
• Creating invoices
• Calendar overview