Skip to main content

​
What the public API reaches

The published contract contains only deliberate /v2 operations. Dashboard workflows, billing, integration administration, and the other authenticated product surfaces are not public API operations. The organization API key determines the organization for every protected request. A caller cannot select another organization through a path, a query parameter, or a request-body field.

​
Protect API keys

A key that leaks reads and writes financial evidence, which makes six habits worth enforcing:
  • rk_ secrets live in a secret manager.
  • Each service holds the least-privilege scope it needs.
  • Development, staging, and production senders hold separate keys. Those keys separate credentials, not data, because Reconify has no sandbox or test mode.
  • Each key has a recorded owning service and operator.
  • An exposed key gets rotated immediately.
  • Keys travel only in the HTTPS Authorization header.
The dashboard shows a new secret once. Afterwards it shows the key name and display prefix, and it cannot recover the secret.

​
Protect provider credentials

Payment integration credentials are stored separately from non-secret configuration in Supabase Vault, and saved secret values never return to the dashboard.
  • Provider credentials match the intended sandbox or live environment.
  • A manual integration URL never carries a credential.
  • A credential gets rotated after exposure, or whenever the provider requires it.
  • Provider health gets re-tested after any credential change.
A provider’s sandbox setting selects the payment provider’s environment. It creates no Reconify sandbox, so submitted events remain real evidence in the organization behind your key.

​
Treat this as customer data

Five categories of value carry customer data:
  • Event fields and metadata.
  • Issue messages and evidence.
  • Investigation notes.
  • Organization and member IDs.
  • Provider identifiers and lookup results.
Amounts, references, tokens, provider identifiers, and customer identifiers get redacted from logs, where X-Request-ID replaces the request body. The same applies to anything leaving your systems: notes carry no credentials or raw financial data, raw API and provider responses stay out of tickets and AI prompts, and a note’s Idempotency-Key is never a secret. When you need help, the redacted support packet carries enough to diagnose and nothing more. Public member responses contain IDs, roles, and join times, and they return no email addresses.

​
Retention and deletion

Monitoring events are immutable evidence. The public API exposes no event-deletion operation, and resolving a finding deletes none of its evidence. This portal publishes no single retention or deletion interval covering every plan and data category. Your organization’s required policy is worth confirming before live financial evidence flows, and neither a dashboard filter nor a missing record in one view implies a deletion commitment.

​
If a credential is exposed

Exposure or suspicious access follows one sequence:
  1. The exposed API key or provider credential gets revoked.
  2. A replacement carries the same least-privilege access.
  3. Every authorized consumer picks up the replacement, and traffic returns to normal.
  4. The UTC timestamp, request ID, key display prefix, and a redacted description go into the incident record.
  5. Reconify status gets checked for a related incident, and the redacted evidence goes to support@reconifyhq.com.