• State Suggested Answer
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 2 subscribers
  • Views 8 views
  • Users 0 members are here
Options
Related

API key rotation with zero downtime

Fatima Al-Rashid

From a governance perspective, we are required to rotate API credentials every 90 days per our information security policy. It is worth noting that we currently have seven production integrations consuming the FieldPulse API, including our customer portal, billing reconciliation service, and two vendor data feeds.

I have confirmed that the API key management interface supports only a single active key per account. When generating a new key, the previous key is immediately invalidated. This presents a significant operational risk: any credential rotation will result in service interruption until all seven integration points are updated and redeployed.

I am seeking clarification on the following points:

  1. Does FieldPulse support multiple concurrent API keys, or is there a mechanism to stage a new key before invalidating the existing one?
  2. If not, what is the recommended approach for credential rotation in high-availability environments?
  3. Are there plans to implement scoped API keys with independent lifecycle management?

Our current workaround involves scheduling rotation during a maintenance window, but this does not satisfy our continuous availability requirements. I would appreciate any guidance on how other organizations have addressed this constraint.

  • 0

    Hey Fatima — yeah, this one is a real pain point and I'm not going to sugarcoat it. The short answer is: no zero-downtime rotation today with a single account key. The key swap is atomic and the old one dies immediately.

    That said, here are the paths I've seen teams take:

    Option 1: Dual Account Strategy (Most Common)

    Spin up a second FieldPulse account as a "staging" environment. Generate your new key there, pre-configure your integrations to read from a key management service (KMS) or secrets manager, and do a hot swap at the application layer. Not elegant, but it works.

    Option 2: Application-Level Key Caching

    Some teams implement a brief overlap by having their services accept both keys temporarily — old key in memory, new key ready to pick up on next deploy. This requires you to control the validation logic, which obviously only works for integrations you own end-to-end.

    Option 3: The Maintenance Window (I know, I know)

    Scoped keys with independent rotation are on our roadmap for H2 — I can say that with some confidence because I'm literally looking at the Jira epic. No firm ETA, but it's getting real design attention.

    For now, I'd recommend documenting your rotation procedure in a runbook and accepting the 5–10 minute blip. Not great, but mitigatable with retry logic and queueing on your side.

    Want me to dig into any of these approaches? I can share some Terraform snippets for the dual-account setup if that's helpful.

  • 0

    +1 to Eli's dual account approach — that's what we ended up doing. Heads up though: if you're using webhooks, you'll need to reconfigure those on the second account too, and the account_id in the payload will be different. Caught us off guard the first time.

    YMMV, but we also found that FieldPulse's rate limits are per-key, not per-account, so running two accounts in parallel during migration actually doubled our throughput temporarily. Worth noting if you're dealing with large backfills.

    One other gotcha: custom field definitions don't sync between accounts, so we had to script a one-time export/import. Took about an hour to sort out.

  • 0

    Thank you for the detailed guidance. The dual account strategy is viable for our use case, though it does introduce meaningful overhead in account management and webhook reconfiguration.

    It is worth noting that we will require formal documentation of the scoped key roadmap item for our audit trail. Is there a public issue or RFC I may reference?

    Additionally, I would request that the product team consider implementing a staged key deprecation mechanism — e.g., a 24-hour overlap period during which both keys are valid — as an interim measure prior to full scoped key support. This would satisfy our security requirements without the operational complexity of account duplication.

  • 0

    Totally fair ask — I'll surface the staged deprecation idea with the platform team. The 24-hour overlap is actually something we've discussed internally; the hesitation is mostly around audit logging and "which key did this" ambiguity, but I think there are ways to solve that.

    Re: public RFC — not yet, but I can add you to the early access list when we move to beta. Shoot me a DM with your account ID and I'll flag it.

    In the meantime, I put together a quick Terraform module for the dual-account setup: gist link. It's rough but should save you some boilerplate. The webhook sync script is in there too.

  • 0

    For audit trail purposes: document the rotation event in your SIEM with both key fingerprints. FieldPulse doesn't expose key metadata (created date, etc.) via API, so you'll need to track that externally.

    Relevant docs: API Rate Limits and Best Practices — note the 429 retry guidance, which you'll want during the swap window.