Security

API keys

Flashpi stores only a SHA-256 hash of each key, so a key is shown once, when it is created, and cannot be recovered afterwards.
Every key can be limited to one issuer, to read-only access and to a list of IP addresses. See Authentication and API keys.
Revoking a key takes effect immediately, without an authenticator code, so a leaked key can be stopped at once. Revoking a live key emails every account owner.
Creating or changing a live key needs an account owner who confirms with their authenticator code.
The request logs record which key made each request and from which IP address, for 30 days, without the bodies.

An uploaded .p12 and its password are encrypted as soon as they arrive, with a key managed by AWS KMS, into a dedicated quarantine area. The password is never stored in clear and never returned by the API.
An isolated onboarding service checks the upload and stores the certificate re-encrypted under a separate key; the raw upload is then deleted. In the onboarding from the certificate, the first check stores nothing: the encrypted upload waits for you to complete the onboarding, which checks it again, stores the certificate and deletes the upload. An upload whose onboarding is never completed (a rejected or expired one included) is deleted automatically about 7 days after it was uploaded.
Only the signing service can decrypt the certificate, in memory, to sign your documents. The API that receives your requests cannot read it.
Certificates are checked with their certification authority for revocation when they are uploaded and regularly afterwards; a revoked certificate never signs. See Certificates.

Every request is signed with HMAC-SHA256 following Standard Webhooks, with a timestamp that limits replays to 5 minutes. Verify the signature before trusting the body. See Webhooks.
Signing secrets are stored encrypted, can be rotated with an overlap, and reading or rotating one in the console needs a fresh confirmation and is audited.
Flashpi only calls public HTTPS URLs. It refuses local names and private, loopback and link-local addresses (cloud metadata addresses included), resolves the host itself on every delivery, connects only to public addresses and never follows redirects.
Flashpi publishes no fixed IP addresses for its webhooks: the signature is the proof that a request comes from Flashpi.

Google sign-in uses an authorization code with PKCE. Google users with an authenticator still enter its code. Flashpi receives the basic Google profile (email, name, given and family names, picture URL and language), without access to contacts or other Google APIs.
Passwords are hashed with argon2id. Repeated wrong passwords or codes block further attempts for 15 minutes.
Two-factor authentication (TOTP) is mandatory for account owners, and owners can require it for the whole team.
Sensitive actions (live keys, certificate uploads, team changes, webhook secrets, two-factor changes, password changes) need a confirmation in the last 10 minutes: an authenticator or recovery code when you have an authenticator, never the password alone.
A user with Google only and no authenticator must enroll one before sensitive actions. Creating a password uses the reset email. Resetting a password disconnects Google and ends existing sessions; support can also remove Google sign-in after checking ownership.
Sessions live on the server behind an httpOnly, SameSite=Strict cookie, last 12 hours and end after 2 hours without activity. Changing your password signs out your other sessions.
An email verification link only completes in the browser that asked for it, or in a browser signed in to the same account.
Security-relevant events, such as sign-ins, two-factor changes and new recovery codes, are recorded, and the important ones are emailed to you.

flashpi.com.ec uses no external fonts or widgets. The public site and these docs load Google Analytics and Microsoft Clarity only if you accept them in the cookie notice, and you can withdraw your consent under “Cookie preferences”, at the foot of every page; until you accept, no external script loads. The console never loads third-party scripts or analytics. The console can load a linked Google profile picture from lh3.googleusercontent.com; that image request gives Google the visitor’s IP and browser information, without the referring URL. All other images and fonts come from Flashpi.
Every page is served with a strict Content-Security-Policy, plus HSTS and protection against framing. The console’s only allows Flashpi’s own scripts and styles; the public site’s and the docs’ also allow the scripts of Google Analytics and Microsoft Clarity, which load only with your consent.
The console calls its API on the same origin, so no cross-origin access is opened.

Error answers never include the SRI’s raw answers or internal details: they carry a stable code and a requestId that support can trace.
Flashpi’s logs redact the Authorization header, cookies and other credentials, and keep paths without their query strings.
Test and live data are kept apart: a test key can never read live documents.

Keep API keys and webhook secrets on your servers, in a secret manager or environment variables, never in front-end or mobile code or in a repository.
Use a separate key per system, the narrowest scope and access that works, and an IP allowlist when your servers have fixed addresses.
Verify every webhook signature against the raw body, and refuse old timestamps.
Send an Idempotency-Key with every POST, so retries never issue a document twice.
Watch the console’s request logs and webhook delivery log, and revoke what you no longer use.