Skip to content
Regulation to Control

Legal

Privacy policy

Last updated 31 August 2026 · applies to the Regulation to Control API and to this website.

Six facts in this document are not yet settled. They depend on the operating entity's legal details, which are recorded nowhere in this service, so they are marked [LIKE THIS] rather than guessed at. They must be filled in before this page is final.

Everything else here describes what the deployed code actually does, and was written by reading it.

In short

  • We collect an email address, a record of what your API key consumed, and payment records. Nothing else.
  • The payloads you send to this API are not stored at all — the only record of a call is the metered usage row.
  • We do not sell or share your data, we run no advertising, and there is no third-party analytics script, tag manager or tracking pixel anywhere on this website.
  • The only cookie this site can set is the sign-in cookie on the dashboard.
  • Payments are processed by Square. Card numbers never reach this service.

1. Who this policy is from

The Regulation to Control API and this website are operated by [LEGAL ENTITY NAME], at [REGISTERED POSTAL ADDRESS]. In this document “we” and “us” mean that entity, and “you” means the person or organisation using the API. You can reach us at contact@nerveplusinc.com.

2. What we collect, and why

2.1 Your email address

An email address reaches us in exactly three ways, and each does something different with it.

Requesting an API key — POST /v1/keys
You supply an address. We email a one-time claim token to it, and we derive your account identifier from it. That identifier is a keyed HMAC-SHA256 of the lowercased, trimmed address, truncated — not a plain hash, so it cannot be reversed by anyone who does not hold the key we keep. On this path the address itself is never written to the database: it is held in the running service's memory for up to a minute, so that repeat requests cannot be used to flood a stranger's inbox, and it travels inside the signed token in the email we send you. If you never claim the token, nothing at all is stored.
Signing in to the dashboard
The dashboard emails you a single-use sign-in link. Here the address is stored, because a dashboard has to recognise you on your next visit. If you only ever use the API and never sign in, this record does not exist.
Buying a plan
Square collects your address on its own hosted payment page. When the payment completes, Square gives us the buyer's address so the plan lands on the same account as your keys, and we store it against that payment record.

2.2 API keys

For each key: the label you chose, the first few characters so you can tell your keys apart, a peppered hash of the secret, its status, when it was created, last used and revoked, and its quota counters. The secret itself is never stored. It is shown once, at the moment it is issued, and we cannot recover it, resend it or read it back — if it is lost, the only route is to rotate.

2.3 Usage records

One row per metered call: your account identifier, which API it was, the billing unit, how many units, which key was used, and the time. This is what your invoice is computed from and what GET /v1/usage reports back to you. Request and response bodies are not part of it.

2.4 What you send to the API

The payloads you send to this API are not stored. Each request is processed in memory and the response is returned; the only record kept of the call is the metered usage row described above, which holds no part of what you sent.

2.5 Dashboard sessions

If you sign in: a session identifier, a hash of the session secret, your browser's user-agent string, the IP address the sign-in arrived from, and the creation, expiry and last-seen times. The user-agent and IP are there so that you can recognise your own sessions and end one you do not.

2.6 Sign-in and claim links

For each link: the address it was sent to, a hash of the token, when it was issued, when it expires and when it was used. They are single-use and short-lived — see section 6.

2.7 Account activity

An activity log of account-level actions: which account, who acted, what they did, what it acted on, and when. It exists so that a disputed change to a key or a plan can be answered with a record.

2.8 Payment records

Your plan, its price, the billing period, the included allowance, units used, overage, the spend cap, the amount charged in whole cents, the payment status, and the identifiers Square issues for your customer record and your stored card. Card numbers, expiry dates and security codes are handled entirely by Square and never reach this service — the checkout page you type them into is Square's, not ours.

2.9 Server logs

Every API request writes one line: a request identifier, which API, the HTTP method, the path, the status code, and how long it took. Not in that line: request bodies, response bodies, API keys, email addresses or IP addresses. The request identifier is also returned to you in every response and in the x-request-id header, so if you quote it we can find the exact request.

3. What we do not do

  • We do not sell, rent or share your data, and we do not disclose it for advertising.
  • There is no advertising, ad network, retargeting pixel, tag manager or third-party analytics script on any page of this website. The pages load nothing from a CDN and nothing from another domain.
  • The landing page records which of its buttons you pressed. Those events are pushed into an array in your browser's memory and are sent nowhere — not to us, not to anyone.
  • The playground in the API reference never sends your API key to the server that serves this website. The key stays in that page's memory for the life of the tab — not localStorage, not sessionStorage, not a cookie, not the URL — and the only place it goes is the Authorization header of requests you send to the API.
  • We do not use what you send to the API to train models, and we do not use it to build any other product.

4. Cookies

One cookie exists on this domain: the dashboard sign-in cookie. It is set only when you sign in, and it carries HttpOnly, SameSite=Lax, Secure and Path=/, with a lifetime of 30 days unless the deployment shortens it. Signing out clears it immediately. Nothing else on this site sets a cookie, and no third party sets one, so there is no consent banner to click through — there is nothing to consent to.

5. Who else processes it

Three, and this is the complete list.

ProcessorWhat forWhat it receives
SquarePayments and hosted checkout Your email address and your card details, entered on Square's own page. It returns the payment result and the buyer's email address to us.
ResendTransactional email Your email address and the message body, when we send you a key claim token or a sign-in link. No marketing email is sent through it, because we send none.
RailwayApplication hosting and the database Everything described in section 2 is stored and served on their infrastructure, and every request reaches us through their edge.

The data is stored in [HOSTING REGION]. We add no other processor without changing this page first.

6. How long we keep it

Three things expire on their own, enforced in code rather than by policy:

  • An API key claim token expires 15 minutes after it is issued and can be spent once.
  • A dashboard sign-in link expires 15 minutes after it is issued, can be used once, and is marked as consumed the moment it is.
  • A dashboard session expires 30 days after it is created, and you can revoke it — or every session on your account — before then.

Everything else — your keys, your usage rows, your payment records, the activity log — is kept for as long as the account exists. We do not yet run an automated deletion schedule, and we would rather say so than quote you a retention period we do not enforce. Payment records are kept for [STATUTORY RETENTION PERIOD FOR PAYMENT RECORDS].

7. Deleting your account and your data

Some of this you can do yourself, right now, without asking us:

  • Revoke a key with POST /v1/keys/{id}/revoke, or replace it with POST /v1/keys/{id}/rotate. Both cost no quota, so they still work when you are over your limit — which is exactly when a leaked key needs killing.
  • Do the same from the dashboard, and end one session or every session from there.

Deletion of the account itself is a request, not a button: there is no self-serve delete endpoint yet, and we will not pretend otherwise. Email contact@nerveplusinc.com from the address the account is keyed to — because the account identifier is derived from that address, writing from it is what lets us find the account at all. We will delete your keys, your usage rows, your dashboard identity and any record we hold against the account, keeping only the payment records we are required to retain, and we will confirm by reply. Today that is done by hand. Our target for completing a request is [RESPONSE WINDOW FOR A DELETION OR ACCESS REQUEST].

If you want a copy of what we hold rather than its deletion, ask at the same address.

8. Your rights

Which statutory rights you have depends on where you are and which law applies: [APPLICABLE PRIVACY LAW AND SUPERVISORY AUTHORITY].

Independently of that, here is what we will do on request, for anyone, anywhere: tell you what we hold about you, correct it, send you a copy of it, delete it, or stop processing it. The route is the same in every case — email us from the address the account is keyed to.

9. How it is protected

  • API key secrets are stored only as peppered hashes. The plaintext exists once, in the response that issued it, and nowhere else.
  • Session secrets are stored hashed, never in plain text.
  • Your account identifier is a keyed HMAC of your email address, not a plain hash of it. The service refuses to start without that key configured, precisely so that an identifier appearing in a log or a database row can never be turned back into a mailbox.
  • A key is scoped to one API. Presenting a Regulation to Control key to another API in this portfolio returns the same error as an unknown key, so a key can never be used to confirm which other services you use.
  • Every stored row carries the account identifier and every read filters on it, so tenant isolation is enforced in the database rather than only in application code.
  • Traffic is served over HTTPS, with HSTS sent whenever the request actually arrived over TLS.
  • Authenticated endpoints deliberately do not enable cross-origin access, so an API key cannot be read out of a web front-end that calls them from a browser.
  • We hold no security certification and claim none. As the home page says, we publish no claim we cannot yet support.

10. Children

This is a developer API sold to businesses. It is not directed at children, we do not knowingly collect data from anyone under 16, and if we learn we have, we delete it.

11. Changes to this policy

If this policy changes, the date at the top of the page changes with it, and the previous version is replaced here rather than quietly amended. If a change materially affects what we collect or who processes it, we will say so at the top of this page.

12. Contact

Questions about this policy, a request about your data, or a privacy concern: contact@nerveplusinc.com. See also the terms of service.