Privacy
What our free public REST APIs record, how long it stays, and who else sees it. Written from the service source rather than from a template, so it describes this system and not a generic one.
Last updated 3 October 2026.
Who operates this service
The service is operated by AI SENSE AS, Postboks 1202 Vika, 0110 Oslo, Norway. Org.nr NO 922 601 151 MVA. Questions about this page go to support@aisense.no.
The short version
The free APIs do not require account registration or payment details. Content sent through temporary endpoints can still include personal data. Agent Inbox stores sender addresses and cleaned mail content, including any names or addresses in that content. We set no cookies and run no browser analytics, advertising or tracking scripts. What we do record is the technical detail of each request, because a public service has to be able to see its own traffic.
What we record
Every request
One line in a server log, written when the answer has been sent: the time the request arrived, your IP address, the HTTP method, the requested path with supported bearer credential segments redacted, the protocol, the status code we answered with, the content type, your browser or client's User-Agent string, and how long the answer took.
URL inputs can still enter the log. Bearer IDs for Storage, Capture, Approval, Schedule, Agent Wake, Heartbeat and Inbox are redacted in supported paths. Queue credentials belong in the Authorization header and Queue query strings are not logged. Other query strings and ordinary URL inputs can be recorded. Several endpoints take their input in the URL rather than in a request body - /url_shortener/{url} receives an entire target address, /ip_reverse_lookup/{ip} an IP address, /domain_ip_lookup/{domain} a domain name. Those values are written to the log along with the rest of the line. Do not put anything sensitive in a URL, here or anywhere else.
MCP request summaries
The MCP method log records time, IP address, method, tool name and User-Agent. It does not record tool arguments or results. Daily summaries retain counts by tool and User-Agent, plus a capped list of individual tool-call events containing time, IP address, tool and User-Agent. These are operational traffic records, not an anonymous count.
Rate limiting
We count requests per IP address to enforce the published limit of 5000 per day. The counter is stored against the address. Since 12 September 2026 we also count the bytes each IP address stores through /storage, to enforce the limit of 80 MB per day. That counter is stored against the address in the same way and resets at the same time.
Optional decision models
The default rule mode of /decide computes the answer in the API itself and does not save request or answer bodies. Selecting a model such as Clef sends the state and questions to the model service, which processes them to produce the answer. The model service receives only the state and questions, not your IP address or other request details. The API records usage counters keyed by an IP HMAC and aggregate durations, outcomes, bytes and token counts. It does not save model input or answer bodies. Ordinary access logs still record IP addresses as described above.
Do not send credentials or sensitive personal data in model requests.
Semantic search
/semantic_search keeps the notes you add, with their optional keys, until the collection expires 24 hours after creation, together with the vectors the embedding model makes from them. Adding notes sends their text to the model service, and a search sends the search text, which is not stored. The model service receives only that text, not your IP address or other request details. The API records usage counters keyed by an IP HMAC and aggregate durations, outcomes, bytes and token counts for these model calls. Deleting a note removes its text and vector at once.
Anyone holding a collection's read token can search its notes and read their text. Do not add credentials or sensitive personal data to notes.
What temporary endpoints store
The following endpoint groups hold temporary state or content:
| Endpoint | What is stored |
|---|---|
/storage | Your request body, byte for byte, unchanged |
/url_shortener | The address you asked us to shorten |
/webhook_capture | The complete inbound request, including all headers and the sender's IP |
/webhook_action | The form you defined and the answer someone submitted to it |
/webhook_schedule | The target URL, delivery time, JSON payload and delivery result |
/agent_wake | Task state and the webhook, human answer or time result. Standard credential headers on webhooks are redacted |
/heartbeat | Check-in timing, the webhook URL and optional payload, or an Agent Wake task ID. The target is removed when the monitor becomes terminal |
/inbox | Disposable address, hashed inbox credential, sender address, subject, received time, cleaned message text, extracted codes and public links. Attachments and raw MIME are not kept in the API state |
/queue | Jobs, payload content, status, attempts, timing, deduplication keys and hashes of role tokens and claim receipts |
/semantic_search | Note text, optional keys, note IDs and timestamps, the embedding vectors of the notes and hashes of the read and write tokens. Search text is not stored |
/lease | Hashed lease identity and owner data, timing, fencing token and an optional completed result. Raw namespaces, keys, owner tokens and fingerprints are not stored |
Webhook Capture deserves particular attention. It records every header a caller sends, and services that post to webhooks routinely include authorisation tokens and signatures in those headers. If you point a third-party service at a capture URL, its credentials will sit in our storage for 24 hours. That is the endpoint working as intended, but you should know it before you use it.
Lease replaces values under secret-shaped field names such as authorization, password, token and api_key with [redacted] before storage. It cannot detect a secret placed under an ordinary field name. Keep credentials and personal data out of Lease results and Heartbeat payloads.
The Queue service writes payload content to its JSON state files without encrypting it. It normalizes object-key ordering and JSON serialization. Authorized readers and claiming workers can read the content. Keep credentials and sensitive personal data out of them. Queue processing does not execute payloads, fetch URLs, make callbacks or send content to outside services.
Agent Queue uses separate read, write and worker bearer tokens issued only at queue creation. A queue ID alone grants no access. REST clients send the required token in the Authorization header, never in a URL. MCP clients pass it as a tool argument. A claim receipt identifies the current attempt and is disclosed only to the claiming worker.
What we do not do
No cookies from the API. No advertising, browser tracking scripts or automated decisions about access based on personal profiles. Operational request statistics are described above. We do not sell or rent anything to anyone. We do not attempt to identify who you are, and without accounts we generally cannot.
IP geolocation via /ip_reverse_lookup runs against database files on our own server. The address you look up is not sent anywhere.
How long we keep it
| Data | Kept for |
|---|---|
| Storage, URL shortener, webhook capture, webhook action, Agent Wake | Up to 24 hours |
| Webhook Schedule | Scheduled for up to 24 hours. The final result can remain readable for another 24 hours |
| Heartbeat | Armed for no more than 24 hours. Terminal timing and delivery state can remain readable for another 24 hours |
| Lease | Until the fixed absolute expiry 24 hours after the first acquisition. Renewals do not extend it |
| Agent Inbox API state | At most 24 hours from creation. Activity does not extend expiry |
| Temporary DNS names | 24 hours from creation, or until deleted. The name and its address are public in DNS for as long as the name lives. The creator's address, a hash of the token and the timestamps are kept with the record on both name servers and are removed within a minute of expiry. The lookup counters on the primary count queries per name and hold no client addresses |
| Raw Inbox mail at the receiving provider | Separate mailbox and provider retention. The 24-hour API expiry does not delete this copy, and the default worker does not configure a purge period |
| Agent Queue, including completed and failed jobs | Until the fixed expiry 24 hours after queue creation. Activity does not extend it |
| Semantic search collections, notes and vectors | Until the fixed expiry 24 hours after creation. Activity does not extend it. A deleted note's text and vector are removed at once |
| Rate limit counters | Shared request counters and the storage byte counters reset at midnight Norwegian time (Europe/Oslo). Queue and semantic search creation use separate fixed 24-hour windows. Inbox creation uses a UTC-day quota |
| Raw server access and MCP method logs | Temporary local copies are pruned after 14 days. Compressed archives are kept for approximately 24 months, with the cleanup threshold set to 744 days |
| MCP daily summaries | No automatic expiry is configured for the daily summary files |
| Machine-access audit log | 12 weeks |
| Decision-model and semantic search telemetry | Snapshots show up to seven UTC dates. Older aggregates and daily IP-HMAC counters are removed on the next state write. With no activity, older physical data can remain. No model bodies or answers are saved in these records |
| Client login attempts | The email address and the time stay in our internal Slack channel until we delete them there. The counters that limit repeated attempts hold a hash of the IP address, not the address, and are kept for one hour |
Once the stated readable period ends, the data becomes unreachable through the API. Cleanup runs on a schedule, so removal of the underlying file can happen after the stated API expiry.
Where data goes
Some endpoints contact another service or a destination you selected. Only the value needed for that call is sent:
| If you call | We ask | And send |
|---|---|---|
/bitcoin/balance/{address} | blockchain.info | The wallet address |
/solana/balance/{address} | api.mainnet-beta.solana.com | The wallet address |
/ethereum/balance/{address} | ethereum-rpc.publicnode.com | The wallet address |
/webhook_schedule | The public webhook URL you supplied | Your JSON payload and the schedule ID |
Capture or Approval with notify_url | The public callback URL you supplied | A completion signal and result URL. The signal does not include captured content or answers |
/inbox | The configured Gmail mailbox over IMAP | Incoming raw mail is received by the provider and read into cleaned API state. The default worker marks messages as seen without deleting them. Permanent deletion of imported mail is optional |
/heartbeat with a webhook action | The public webhook URL you supplied | The heartbeat miss event and your optional JSON payload |
Creating a short link stores the destination mapping within this service and returns a 307.fi URL. Creation does not contact the destination or send it to a separate redirect provider.
No other free REST endpoint sends your supplied content to a fixed third party. An Agent Wake heartbeat action stays inside AI SENSE.
The client login on aisense.no/login has no accounts behind it yet. When someone uses it, the email address typed into it and the time are sent to our internal Slack channel, so that we can see the attempt and offer access. The password is cleared in the browser and never sent anywhere, and the page says that you were not signed in.
Calls from other websites
Our API responses permit cross-origin requests from any website, which is what makes the endpoints usable directly from browser JavaScript. A consequence worth stating plainly: if a site you visit calls our API from your browser, your IP address reaches us and is logged, even though you never visited us. We have no way to know which site that was, and we do not receive a referrer for it.
Your rights
Under the GDPR you may request access to personal data we hold about you, its correction or erasure, a restriction on how we use it, or a copy of it - and you may object to our use of it. Write to support@aisense.no.
One practical limit, stated because it is true rather than to avoid the obligation: log entries and rate-limit counters are stored by IP address and nothing else. If you ask us to find your records, an IP address is all we can search on, and shared or dynamic addresses mean we may not be able to distinguish your requests from someone else's. Data you stored through /storage is different - quote the storage_id and we can act on it precisely, though it will have expired within 24 hours anyway.
You may complain to the Norwegian Data Protection Authority, Datatilsynet, at datatilsynet.no.
Why we are allowed to do this
We rely on legitimate interest for the technical logging and rate limiting described above: operating a public service, keeping it available, and investigating abuse and faults. The same applies to the address typed into the client login: someone asking for access may want to be contacted about it. The data is limited to what those purposes need and is not used for anything else. Where you send us content deliberately - anything you post to the storage or webhook endpoints - you are asking us to hold it, and we hold it only for as long as stated.
Security
All traffic is served over HTTPS. The service holds no account credentials because it issues none. Temporary data is addressed by an unguessable bearer identifier, or by a Lease namespace and key. Treat these values as secrets. Anyone holding the right value can read the associated public state or result.
Changes
When the service changes, this page changes with it. The date at the top is the last time it was checked against what the code actually does.