Sandbox environment for API development

Question

Before we commit to building our integration against the production API, we need to understand the availability and characteristics of any sandbox or test environment.

Specifically:

Is there a dedicated sandbox environment with isolated data, or should we use a production account with test data?
If a sandbox exists, does it mirror production API versions and behavior (e.g., rate limits, webhook delivery semantics)?
Are there restrictions on data persistence or account longevity that would affect our CI/CD pipeline testing?
Does the sandbox support the full OAuth flow, including refresh token rotation?

We are particularly concerned with the fidelity of webhook delivery and idempotency guarantees, as our integration depends on reliable event ordering for work order state transitions.

References to relevant documentation or RFC-style specifications would be appreciated.

Eli Torres (Staff) · Accepted Answer

Hey Omar — good questions, and yeah, this is one of those areas where the docs could be clearer.

Short version: we don't have a separate sandbox environment with isolated infrastructure. What we recommend is creating a dedicated "test" account in production (e.g., yourcompany-sandbox) and using that for development. The API behavior is identical — same rate limits, same webhook semantics — but you're hitting production endpoints with non-production data.

Some specifics on your points:

Rate limits: Same 100 req/min per token, including on test accounts. We don't have a "lax mode."
Webhook delivery: Identical to production. If you need to test failure/retry behavior, point your test endpoint at something that returns 500s intentionally.
Data persistence: No automatic cleanup. You're responsible for wiping or archiving test work orders if you care about clutter.
OAuth: Full flow supported, including refresh tokens. Test accounts can go through the same /oauth/token dance.

For CI/CD, we've seen folks use environment-level isolation (separate FieldPulse account per branch) or just partition by naming convention within one account. YMMV on cost vs. hygiene there.

One gotcha: webhook signatures use the same secret per app, so if you're running tests against a public tunnel like ngrok, rotate that secret afterward — it's easy to forget and leave a dev key in prod.

Docs link: Using the FieldPulse API covers auth, and Setting Up Webhooks has the verification details.

Let me know if you want to dig into the idempotency guarantees — that's a longer conversation.

Devon Marsh · Answer

+1 to Eli's approach — that's exactly what we did. Heads up though: if you're using webhooks heavily, the lack of replay/debug tooling in "test" accounts is a pain. We ended up building a small proxy that captures and redelivers payloads so we can replay scenarios without regenerating work orders. Also worth noting: test accounts still count toward your org's seat licensing if you're on a paid plan, so we ended up creating a single shared sandbox account with strict naming conventions ( TEST- prefix on everything) rather than one per developer. YMMV if your security model requires isolation. Re: idempotency — the API doesn't provide native idempotency keys (no Idempotency-Key header), so we had to implement client-side deduplication on our end. Just something to plan for if you're doing retries.

Fatima Al-Rashid · Answer

From a governance perspective, it is worth noting that using production infrastructure for development — even with "test" data — may have implications for compliance frameworks that require environment separation (e.g., SOC 2 Type II, certain ISO 27001 controls). We have elected to proceed with the single sandbox account approach Eli described, but with the following controls: API tokens generated for CI/CD use IP allowlisting restricted to our build environment egress Webhook endpoints require mutual TLS authentication in addition to signature verification Quarterly attestation that no production customer data has been introduced into the test account It is also worth noting that FieldPulse's data processing agreements do not currently distinguish between "production" and "test" accounts for liability purposes. This is a gap we have raised with our account team.