Legal

Privacy Policy

Korlogic is an API gateway. There is no signup form, no password and no email address on file — the API key is the whole account. This page describes exactly what the service records, what it deliberately does not, and who else is involved in a request.

No revision date has been set for this document.16 sections

Section 01. Who runs this service (permalink)

The service described here is operated by Not set: Registered company name. Where this policy says we, it means that business; where it says you, it means the person or organisation holding an API key.

Operator identity and contact details
Detail	Value
Trading name	Korlogic
Registered name	Not set: Registered company name
Registered address	Not set: Registered address
Support	support@korlogic.com
Privacy requests	privacy@korlogic.com
Governing law	Not set: Governing law
Jurisdiction	Not set: Jurisdiction

This policy covers the website at https://korlogic.com and the API served from https://api.korlogic.com/v1 and https://api.korlogic.com/token/v1.

Section 02. The short version (permalink)

The detail is below, but the shape of it is short enough to state plainly.

No account, no profile. There is nothing to sign up for. We do not ask for your name, your email address or a password, and there is no verification step that would collect one.
The key is stored as a hash, not a key. We keep a SHA-256 hash of your API key and the first few characters for display. Nobody here can read your key back to you.
Prompts and completions are not stored. Request and response bodies stream through the gateway. They are not written to the database and not written to our logs. What is recorded is the metering: model, token counts, cost, latency, status, timestamp.
A third party runs the models. Your request content is forwarded to an external model provider so it can be answered. That is unavoidable — it is what an API gateway does.
We never see your card. Payment happens on the payment provider’s own page or widget. Card numbers, bank credentials and wallet details never reach this service.
No analytics, no advertising, no third-party trackers. This site loads no tracking or advertising scripts, and nothing here is sold or shared for marketing.

Section 03. There is no account to sign up for (permalink)

Access is granted by the operator issuing a key, not by you registering. There is no signup form anywhere on this site, no password to choose and no email to confirm. Signing in at /login means pasting the key you already hold; possession of the key is the entire proof of identity.

What is stored alongside a key

Data held against an API key
Stored	Detail
Key hash	A SHA-256 hash of the full key. The key itself is never written to storage, which is why a lost key can only be replaced, never recovered.
Key prefix	The first characters of the key, kept so a key can be identified in a list without revealing it.
Label and customer	Two free-text fields the operator fills in when they create the key, so they can tell their keys apart. These are whatever the operator typed — which may be your name, your company or your email address if that is how they chose to identify the key. We do not collect them from you.
Settings and balance	Billing mode, credit balance and lifetime credit granted, token budget and tokens used, model allowlist, rate limit, status, optional expiry date, and when the key was created and last used.

What a signed-in session holds

Signing in creates a session row containing a hash of a random session token, the internal id of the key it belongs to, the IP address the sign-in came from, and timestamps. The key is deliberately not stored in the session, so a stolen session cannot be turned back into a key. Sessions last 30 days and are destroyed immediately when you sign out, and when the key is suspended or deleted.

Section 04. What is recorded when you call the API (permalink)

Every request that reaches the gateway and produces a billable result writes one row to a usage ledger. That ledger is what the usage checker and your dashboard read from, and it is the basis on which you are charged. It records the following, and nothing else.

Fields written per API request
Recorded	Why
Timestamp	Ordering, daily counts, and your recent-request list.
Key	The internal id of the key that made the request, so usage is attributed to the right balance.
Model	The model id. This is the one field read out of your request body — it is needed to price the request and to enforce the key’s model allowlist.
Token counts	Input, output and total tokens, as reported by the model provider.
Cost	What the request cost you, in integer micro-dollars, plus the operator’s own cost and margin figures where they are known. The operator’s figures are internal and are not shown to you.
Latency	How long the exchange took, in milliseconds.
Status	Success or error, and the HTTP status code. On a failure the ledger stores a short machine code such as `upstream_error_502` — a code, never the text of an error and never any part of your request.
Request ids	Our request id and the provider’s, so a single call can be traced when you report a problem.

Requests that are refused before they reach the provider — an unknown key, a suspended or expired key, a model outside the allowlist, an exhausted balance, or a request over the rate limit — are refused and not billed. Successful metadata calls that produce no token usage, such as listing models, are not written to the ledger at all, so your request counts stay truthful.

Section 05. What is never recorded (permalink)

Your prompts, system prompts, messages, attachments, tool definitions and the model’s replies are streamed through the gateway and then gone. They are not written to the database, and they are not written to our application logs. The usage ledger has no column that could hold them, and the activity log records only what a request was — its path, its model, its token counts and its cost — never what it said.

Two things do happen to a request body in transit, and both are worth stating precisely:

The model field is read out of it, for pricing and allowlist enforcement.
On streaming requests, one field is added asking the provider to report token usage in the final event. Without it a streamed request would meter as zero. Nothing else in your body is inspected or altered.

Section 06. The model provider (permalink)

Korlogic does not run the models. It is a gateway: your request is forwarded to a third-party model provider, which processes the content of that request in order to generate a reply, and the reply is streamed back to you. There is no way to use this service without that happening.

Your credentials are not part of that forwarding. Your API key is stripped from the request before it leaves — the gateway authenticates to the provider with the operator’s own account credentials — and the provider never learns which key of ours made the call. Cookies, forwarded-for headers and other identifying headers are removed on the way out as well.

The provider is chosen by the operator, and this service deliberately does not name it on customer-facing pages. How that provider handles request content is governed by its own terms rather than by this policy. If your use case requires knowing who processes your data, ask the operator before you send anything sensitive — the contact details are in section 01.

Section 07. Paying for credit (permalink)

Credit is bought through a payment provider the operator has enabled. Depending on which they chose, that means being redirected to the provider’s own hosted page, having a form posted to it, or opening the provider’s widget inside this page.

Nor do we hand your details to them, because we do not have any. Some payment providers refuse an order without a customer email address or phone number; where that is the case, the operator configures a placeholder that is sent instead. Your own contact details are never collected for this purpose.

What an order records

An order reference, the key prefix it is for, and the internal id of that key.
Which payment provider was used, and whether it was in test or live mode.
Amounts, in integer micro-dollars: the base amount, any gateway surcharge the operator sets, any discount, the total charged, any bonus credit, and what was ultimately credited — plus the currency the provider was actually asked to charge in.
The provider’s own order and payment identifiers, and, on a failure, its stated reason.
Status and timestamps: created, pending, paid, failed, expired or refunded.
A record of every callback the provider sent, with its event identifier and whether its signature verified — which is how a redelivered notification is recognised as a repeat rather than a second payment.

The gateway credentials used for an order are stored encrypted and frozen at the moment the order is created, so rotating a key later cannot break the verification of a payment already in flight.

Section 08. Coupons, codes and referrals (permalink)

Where the operator runs promotions, the records are minimal and are always tied to a key rather than to a person.

Coupons and offers. When a code is applied to a paid order, we record which code, which key, which order, and what it was worth. This exists to enforce per-code and per-key usage limits.
Redeem codes. We record that a given key used a given code and what it granted, so the same code cannot be claimed twice by the same key.
Referrals. A referral link carries a code. That code is parked in a first-party cookie for 30 days and spent the first time we can see a signed-in key, because the click and the key are almost never the same visit. What is then stored is a link between two keys, the amount earned, and the amount claimed. A key can only ever be attributed once, and a key cannot refer itself.

The referral reward percentage and the minimum claim amount are set by the operator, so this policy does not state figures for them. The current values are shown on the referrals page when you are signed in.

Section 09. Support tickets and notices (permalink)

Support runs on tickets rather than email. Opening one at /dashboard/tickets stores a ticket number, the subject you typed, the key it belongs to and its prefix, a status and priority, and every message in the thread with its author and time. Only that key can read the thread, and the operator replies inside it.

Site-wide notices work the same way. When you dismiss one while signed in, we record that this key dismissed that notice so it does not reappear. When you are not signed in, the dismissal is kept in your browser’s session storage instead and never reaches us.

Section 10. The account activity log (permalink)

Separately from the usage ledger, an activity log records actions taken on an account: a key being created, suspended, resumed or adjusted, a code redeemed, referral credit accrued or claimed, a request completing or being refused. Each entry stores who acted (the operator, the system, or you), what the action was, a small structured detail object, the IP address the action came from, and the time.

The detail object describes the shape of what happened — a request path, a model id, token counts, an amount, an HTTP status — and never the contents of a request or a reply.

IP addresses. To be plain about it: an IP address is recorded against entries in this activity log, and against each sign-in session. This is the only place your network address is retained. It is there so the operator can investigate abuse of a key and unauthorised access, and it is not used to build a profile or shared for marketing.

Section 11. Cookies and browser storage (permalink)

There is no cookie banner here because there is nothing to consent to: this site sets no advertising, no analytics and no third-party cookies. Every item below is first-party and functionally necessary. This is the complete list.

Every cookie and browser-storage item this site uses
Name	Kind	Purpose	Lifetime
kl_user	Cookie	Your signed-in session. Holds a random token, not your API key. Set only when you sign in, and marked HTTP-only so page scripts cannot read it.	30 days
kl_admin	Cookie	The operator’s own administrative session. This is never set on a customer’s browser — only on the browser of whoever signs in to the admin area.	7 days
kl_ref	Cookie	Remembers the referral code from a share link, so a key you sign in with later can be attributed to whoever referred you. Grants nothing on its own.	30 days
korlogic:theme	Local storage	Your light or dark preference. Not a cookie — it stays in your browser and is never sent to the server.	Until cleared
Pasted key	Session storage	A key you paste into the usage checker or the top-up page is held in the tab so a refresh does not lose it. Never written to a cookie or to local storage.	Until the tab closes
Dismissed notices	Session storage	Which site notices you closed, when you are not signed in.	Until the tab closes

The typefaces this site uses are bundled with it at build time rather than fetched from a font service, so loading a page does not announce your visit to a third party.

Nothing here is sold, rented or shared for advertising. There are exactly four ways data leaves this service, and all of them are structural.

The operator. Whoever runs this deployment can see every key, its balance, its usage ledger, its orders, its activity log and its support tickets. They cannot see your API key or your prompts, because neither is stored.
The model provider. Receives the content of your request, because that is what answers it. Receives no key of yours and no cookie.
The payment provider. Receives an amount, a currency and an order reference. Receives your card details directly from you, never through us.
The infrastructure this runs on. Hosting and network providers necessarily handle traffic in transit. The operator chooses these.

Beyond that, data may be disclosed where the operator is legally compelled to disclose it, or where it is necessary to investigate abuse, fraud or a security incident.

Section 13. How long any of it is kept (permalink)

Some of this is fixed by how the software works, and some of it is the operator’s decision. It would be dishonest to print a single retention period as if it were both.

Sessions expire 30 days after sign-in, and are deleted immediately on sign-out or when the key is suspended or deleted.
The referral cookie lasts 30 days and is cleared as soon as it has been used.
The usage ledger, the order ledger and the activity log are append-only records that the software does not delete on a schedule. They are financial and security records, and they persist until the operator removes them.
Support tickets persist until the operator deletes them or the key they belong to is deleted.

There is no automatic expiry job for the ledgers. If you need a specific retention commitment — a maximum period, a deletion schedule — that is a question for the operator, who can answer it for their own deployment. Ask at privacy@korlogic.com.

Section 14. How it is protected (permalink)

No claim of certification is made here, and none should be inferred. What can be stated is what the software actually does.

API keys are stored only as a SHA-256 hash. There is no reversible copy anywhere, which is why a lost key is replaced rather than retrieved.
Session tokens are random values stored only as hashes as well, and the session cookie is HTTP-only, same-site and marked secure in production.
A browser presenting two different session cookies is refused outright rather than having one of them picked, and signing in destroys any session the browser was already holding.
Your key is stripped from every request before it is forwarded, so it cannot leak to the model provider. The operator’s own provider credentials live in the server environment and are never returned in a response, shown in the interface or written to a log.
Payment callbacks are rejected unless their cryptographic signature verifies, and an order is fulfilled exactly once, so a replayed or duplicated notification cannot credit a key twice.
Payment-provider credentials are stored encrypted, and are write-only in the admin interface.

None of this makes a leaked key safe. Anyone holding your key can spend your balance, so treat it as a password and ask for it to be suspended the moment you suspect otherwise.

Section 15. Your choices, and what deletion does (permalink)

Depending on where you live you may have rights to access, correct, export, restrict or delete personal data held about you. This service is small and the data is thin, so most requests come down to one of three things.

See what is held. Most of it is already visible to you: the usage checker and the dashboard show your key’s balance, its usage history and its orders without asking anyone.
Correct it. The only free-text fields about you are the label and customer identifier on your key, both written by the operator. Ask them to change either.
Delete it. Ask the operator to delete the key.

What deleting a key actually does

Being specific about this matters more than a general promise:

Removed outright: the key row itself, its hash, its label and customer fields, its balance, every session for it, its referral account and referral links, and its record of which redeem codes and notices it used.
Kept, but detached: the usage ledger, the order ledger, the activity log, coupon redemptions and any support tickets. These rows survive with their link to the key set to null. They remain as accounting and security records of transactions that really happened, but they no longer point at your key.

To make a request, open a ticket at /dashboard/tickets if you can sign in, or write to privacy@korlogic.com. Include your key prefix — the visible first characters — so the right key can be found. Never send the key itself. If you are unhappy with how a request was handled, you may be able to complain to a data-protection authority where you live.

Section 16. Changes, and how to reach a human (permalink)

This policy may be updated as the service changes. The revision date is shown at the top of this page; where no date is shown, the operator has not recorded one. Continuing to use the API after a change means the current version applies to you, so it is worth re-reading if you rely on any specific statement here.

Questions about this policy, or a request under it, go to privacy@korlogic.com. General support goes to support@korlogic.com or, better, to a ticket at /dashboard/tickets where it is tied to your key. If you cannot sign in, use the contact page.

The other two documents on this site are the Terms & Conditions and the Refund Policy.