API Terms of Use

This is a deliberately complete commercial agreement, and it is written to protect Sirveil. It should be. We operate against well-funded adversaries in an industry that litigates.

But understand what it is for. The fence in Section 7 is not there to catch you out — it is there because the entire premise of this company is that personal information should be harder to weaponize, and an API that answers questions about people can be turned into a weapon by the wrong buyer. Everything else in here — the license in Section 12, the billing rules in Section 10, the honest indeterminate in Section 9 — is written to give you more than the industry standard, not less. We would rather tell you exactly when we charge you and exactly what we cannot promise than win an argument later on wording you never read.

You will also find, in Sections 6.1, 9.1, 11.1 and 15.1, a plain list of things we do not have, do not check, and will not promise: the certifications we do not hold, the vendors that necessarily see an identifier in clear text, the numbers in our own responses that you should not build a threshold on, and the limits that can refuse your call. None of that is in here because a lawyer made us. It is in here because you would find it in diligence anyway, and a buyer who learns it in month six is a buyer we mis-sold.

These API Terms of Use ("Terms") are between Sirveil, Inc., a Delaware corporation ("Sirveil", "we", "us"), and the business or professional entity that opens an API account or purchases access through a marketplace ("Customer", "you").

They cover the Sirveil Exposure API (the "API" or "Service") and nothing else. The Sirveil consumer application has its own separate Terms of Service and Privacy Policy, which do not govern API use and are not modified by these Terms.

• Verification — a call to POST /api/v1/verify, and the billed SKU of that name.
• Scan — a call to POST /api/v1/scan, and the billed SKU of that name. (These are the names that appear on your invoice. Sales conversations may say "check" and "sweep"; the contract and the invoice line say verification and scan.)
• Answer — the response the Service returns to a billable call: for a Verification, the three-state verdict together with its evidence and explanation; for a Scan, the ranked, tiered, cited exposure cards together with the coverage block.
• Billable Answer — an Answer that Sirveil delivers, or makes available for retrieval, in response to a properly authenticated and well-formed call. An Answer is a Billable Answer whether it was computed fresh or served from cache, whether the verdict is favorable to you or not, and whether or not you retrieve it. Not a Billable Answer: a call refused before any lookup occurs; a call rejected as malformed or unauthenticated; and an Answer Sirveil could not serve because of a fault on Sirveil's side or in an upstream provider (an "Unserved Call"). (See Section 10 for how each case bills.)
• Documentation — the API documentation Sirveil publishes for the Service, including the OpenAPI document the Service serves, as updated.
• Identifier — a data element about a natural person that you submit in a call.
• Output — the Answers, evidence, reports, and other material the API returns to you.
• Rate Card — Sirveil's published per-call prices for the Service, as in effect from time to time: the prices published in the Documentation and, for a purchase made through a Marketplace, the prices published on that Marketplace listing. Prices are not reproduced in these Terms, so that a price change is not an amendment to them.
• Registry — Sirveil's maintained list of domains and sources, against which findings are classified and over which coverage is reported. The Registry is not the list of domains a Scan queries. See Section 6.
• Subject — the natural person an Identifier relates to.
• Marketplace — AWS Marketplace, or another reseller or marketplace through which Sirveil makes the Service available and through which you purchase access. Section 3.1 states which channels are actually available.

The agreement between us consists of, in descending order of precedence:

1. a signed written enterprise agreement between you and Sirveil, if one exists;
2. these Terms;
3. the Acceptable Use Policy (AUP), which is incorporated by reference and is part of these Terms;
4. the API Privacy Notice, incorporated by reference;
5. the Documentation and the Rate Card.

Marketplace purchases. If you buy access through a Marketplace, that Marketplace's own terms govern the transaction — ordering, invoicing, metering submission, taxes, refunds, and entitlement — and control over these Terms to the extent of a direct conflict on those subjects only. These Terms govern use of the Service in all other respects. Where a Marketplace requires Sirveil to offer an end-user license agreement on the listing, these Terms are the document Sirveil offers there, and the version displayed on the listing when you subscribe is the version that governs your purchase. Any refund or cancellation policy published on that listing applies to the transaction and is in addition to anything in these Terms; nothing in these Terms narrows it.

You accept these Terms by accepting them at account creation or key issue, by purchasing through a Marketplace, or by calling the API — whichever happens first.

3.1 Channels through which the Service is sold

The Service is available for purchase through AWS Marketplace. That is the whole list today.

Sirveil's published specification, documentation, and integration artifacts may name other channels — a marketplace whose listing is built but not selling, an API aggregator, or a direct checkout — because they exist in code. A channel named in an artifact is not an offer, and is not available until it is listed in this Section. Do not build a purchasing integration against a channel that is not listed here; if you have, tell us at [email protected] before you rely on it.

Sirveil may add or remove a channel. Removing a channel is a change to how the Service is sold, not a reduction of the Service you have already bought; if it affects an account you are actively paying for, Section 11 applies.

The Service is offered only to businesses and professional users, only in the United States, and only to persons who can form a binding contract. It is not offered to consumers for personal use, and it is not offered to anyone barred from receiving US goods or services under sanctions or export-control law.

You represent that you are not located in an embargoed jurisdiction, are not on a US government restricted-party list, and will not make the Service available to anyone who is.

• Access requires an account and a secret API key. Keys are bearer credentials: anyone holding one can spend your money, so treat one like a password.
• A key is displayed once, at issue. Sirveil stores only a cryptographic hash of it, together with a short non-usable prefix for identification, and cannot recover, re-display, or email you an existing key. If you lose one, issue a new key and revoke the old one.
• An account may hold up to ten unrevoked keys. Revoking a key does not delete its history: usage already recorded stays attributed to the key that produced it, which is what makes an invoice auditable.
• All use under your key is your use, and you are responsible for it, including use by your personnel and contractors and by end users reaching the Service through your application. That does not permit sharing a key with another legal entity.
• One key, one organization. Keys may not be shared across legal entities, sold, sublicensed, or embedded in a client application where an end user can extract them.
• Tell us immediately at [email protected] if a key is exposed. We will revoke it, and you can revoke and reissue keys yourself from the console at any time. We are not responsible for charges incurred before you tell us, except to the extent the law says otherwise or the exposure was our fault.
• Use-case attestation. At key issue, and on request afterwards, you will tell us truthfully what you are using the Service for. We may require any account to certify its use case in writing, and may condition, suspend, or refuse access on that certification or on a refusal to give one. We do not undertake to require certification from every account, and not requiring it from you is not a waiver of the right to require it later, nor a representation that we have vetted any other account.

The Service answers one question — does this identity appear in the sources we can reach, and where — in two shapes.

A Verification (POST /api/v1/verify) asks whether an identity you name is indexed on one domain you name. It is one search-index question, answered in three states, with the evidence and an ordered plain-language explanation of what was queried and what matched.

A Scan (POST /api/v1/scan) sweeps for one identity across multiple source lanes and returns ranked, tiered, cited exposure cards together with a coverage block that names what we did not reach.

What a call must carry. Both endpoints require firstName and lastName; a Verification also requires a domain. That is not form validation — the name is the anchor every candidate record is scored against, and without it the Service has no way to tell whether the record it found is the right human being. A request missing them is refused with 400 identity_incomplete before any lookup runs and before anything is charged. Everything else — phone, email, street address, city and state, date of birth, usernames — is optional, and the more of it you send, the more the query planner has to work with: it leads with a held identifier where it has one, in the order phone → email → street address → name. A field we cannot parse is dropped rather than guessed at, and the name of the dropped field is returned to you in dropped_fields, so a formatting mismatch surfaces as a line in the response instead of a thin result you cannot explain.

⭐ Where a call goes — and Verification and Scan are not the same.

• A Verification reaches exactly one third party: the search provider. It makes no model calls. It reaches no identity-enrichment vendor, no breach or stealer-log vendor, no court-records source, and no username site. One site:-scoped query, one provider, one answer. (A failover search provider may stand in for the primary where the primary fails. That is the same single category of recipient and the same single call — not an additional one.)
• A Scan reaches more, and we will not blur the two together. In addition to the search provider, a Scan may query identity-enrichment sources, breach and stealer-log sources, court-record sources, and public username pages, and it uses model inference for parts of its adjudication and phrasing. Some of those sources are commercial subscription data — an enrichment vendor and breach-corpus vendors are paid services, not public web pages.

Section 6.1 states what each category of recipient actually receives.

Coverage on a Verification is your list, not ours. There is no domain allowlist. You name any hostname and we query it; reach is not narrower than "anything you name" — it is anything you name.

⛔ The one exclusion. A request naming a domain in the facial-recognition and biometric identification class — a service whose primary function is identifying a person from an image or a biometric template — is refused with 403 domain_excluded before any query is built and before any money is spent. That is a control in the code, not a policy we apply by hand, and it is not waivable.

Coverage on a Scan, stated precisely. The base sweep queries a pinned set of twelve people-search domains; a typical run issues on the order of thirty to fifty site-scoped queries in total, and the number varies with what you send us and what comes back. The Registry — a set of several hundred domains (currently 548) derived from the California data-broker register, a public record you can audit, plus a curated priority set — is what findings are classified against and what coverage is reported over. It is not the query list, and a Scan does not query every domain in it. Every Scan returns a coverage block naming the domains in the expected set that were not reached, up to a per-response limit. We publish what we missed; that is unusual and it is deliberate.

What the Service is not. An Answer is a point-in-time observation of an index. It is not a statement about a person. The Service is not a consumer reporting agency, credit bureau, background-check, tenant-screening, or employment-screening product; not a facial-recognition or biometric system; not a law-enforcement tool; not a location service; and not legal advice. See the AUP and Section 7.

How the Service behaves toward third-party sites. The crawler the Service uses to fulfill your calls identifies itself honestly by user agent, does not log into third-party services, does not solve or bypass captchas, does not circumvent technical access controls, and honors robots.txt, failing closed — including when it cannot retrieve or parse a robots.txt at all. That describes the Service; it is not a representation about Sirveil's other internal systems.

6.1 Subprocessors, and what each one receives

To answer your call, the Service sends data to third parties. Stated by category, honestly:

Retrieval vendors necessarily receive the Identifier in clear text. That is what a lookup is — there is no way to ask an index whether a phone number appears on a page without sending the phone number. We are not going to pretend otherwise, and any vendor who tells you their retrieval works differently is describing a different operation.

The model path is different, and it is enforced rather than promised. Sensitive values are tokenized before any model call, and a check runs on the outbound payload: if a raw sensitive value survives tokenization, the call is aborted rather than sent. Model routing is pinned to US-hosted providers, configured to deny data collection and to request zero data retention.

The current list of named subprocessors is available on request at [email protected], and we will provide it to a Marketplace or enterprise buyer under a confidentiality undertaking. We do not publish the list, because it is also a map of our supply chain. Sirveil may add, remove, or replace a subprocessor within these categories.

6.2 How you call it: shapes, timing, and the agent surface

Three shapes, one implementation.

1. Synchronous — the default. The Service returns the result body when the run finishes.
2. Streaming. Accept: application/x-ndjson yields progress events followed by the identical result body.
3. Asynchronous — strictly opt-in, by a named header. Send Prefer: respond-async and you receive 202 with a job id; poll GET /api/v1/jobs/{id} for the result. Async is not the default shape, and an integration built as though it were will receive a result body where it expected a job id.

Async mechanics. A job holds its input and its result for 24 hours, after which the identity and the result are purged and the job's id, status and timings remain, so a late poll receives an explicit expiry rather than an answer indistinguishable from a bad id. Polling a job is free and consumes no quota. A job id belonging to another tenant returns 404, never 403 — we do not confirm the existence of someone else's job. If async is unavailable on a deployment the call returns 503 async_not_available and charges nothing.

Free endpoints. GET /api/v1/whoami (which reports the plan, limits, and channel that apply to your account) and GET /api/v1/jobs/{id} are free and consume zero quota.

Timing, as measured — not as promised. In Sirveil's own instrumented runs, a Verification had a median latency of 890 ms and a 95th-percentile latency of 1,463 ms (n=18, cache-cold), and a synchronous Scan had a median of 154 seconds and a maximum of 203 seconds (n=5). Those are measurements of our runs on our data, not a performance commitment, and Section 15 disclaims any warranty about them. Two practical consequences: do not describe a Verification as "about a second," and set a read timeout of at least 240 seconds on a synchronous Scan or use the async shape.

The agent surface. POST /api/v1/mcp is a read-only Model Context Protocol server exposing a single verification tool. There is no scan tool. A call through it is a Verification and bills as a Verification; we say that here because a buyer who discovers it on an invoice is a refund request.

Permitted use is broad. You may use the Service and the Output for any lawful business purpose, including inside products you build and sell, subject only to this Section and the AUP. Inside the fence, your business is your business.

⛔ The fence. You will not, and will not permit anyone else to, use the Service or the Output:

1. for any purpose regulated by the Fair Credit Reporting Act, 15 U.S.C. §1681 et seq., or a state analogue including Cal. Civ. Code §§1785 and 1786 — including as a factor in establishing a person's eligibility for credit, insurance, employment, housing or tenancy, education, a government license or benefit, or any other purpose enumerated in §1681b(a)(3);
2. to stalk, harass, dox, intimidate, threaten, or locate a person for the purpose of causing harm, or to facilitate anyone else doing so;
3. for facial recognition or biometric identification — you will not submit face images, face embeddings, or other biometric identifiers or templates, and you will not use Output to build, train, operate, or enrich a facial-recognition or biometric-identification system;
4. with credentials or sensitive material you have no lawful right to submit — passwords, password hashes, session tokens, full payment-card data, government-ID images, or data from a breach or dump;
5. to attack, probe, overload, reverse engineer, or circumvent the Service, its security, or its metering, or to test it beyond documented limits without our written agreement;
6. to misrepresent Output as a government record, a background check, a credit or consumer report, a certification, or a determination about a person; or
7. in violation of any applicable law, or of a third party's terms of service, where you direct the Service at that third party.

Your representations about what you send. For every Identifier you submit, you represent that you hold it lawfully, that you have a lawful basis to have us process it, and that you are not knowingly submitting the Identifier of a person you know or reasonably should know is under 18. The Service does not screen for age and performs no date-of-birth boundary check; this representation is the control, and it is yours. Nothing in these Terms obliges Sirveil to detect, verify, or refuse an Identifier relating to a minor. Flow-down. If you make Output available to your own customers, you will impose these same restrictions on them by contract, require each of them to impose the same restrictions on every further recipient, and name Sirveil as an intended third-party beneficiary entitled to enforce them. You remain responsible for your customers' compliance.

We may check. We may monitor usage patterns for signs of prohibited use, ask you to explain a pattern, and require the certification described in Section 5. Nothing here obliges us to monitor, and no failure to detect misuse waives anything.

You are the controller of the Identifiers you submit and you decide why they are submitted. For those Identifiers, Sirveil acts as your service provider (as defined by the CCPA) and processor: we use them to answer your call and for the limited retained purposes described in the API Privacy Notice, and we do not sell them, share them for cross-context behavioral advertising, retain them beyond the periods stated below, combine them with other data except as permitted, or use them to build or enrich a separate product.

What is kept, and for how long — all three cases.

1. A synchronous Verification or Scan does not persist the identity you submitted or the Answer we returned. The verification path is guarded in code against writes.
2. An asynchronous job must hold its input and its answer between submit and poll. That job is retained for 24 hours, after which the identity and the result are purged and only the job's id, status and timings remain.
3. Every authenticated call writes one activity row — the account, the key, the endpoint, the timestamp, the status, the latency, the units billed, the outcome, an internal run identifier, and our own cost of serving the call. It contains no request body and no response body, and therefore no Identifier and no Answer. That row is the billing record, and it is retained indefinitely.

We would rather write the third line than tell you we keep nothing, because we do keep that one row and an invoice you can audit depends on it.

A short-lived in-memory query cache also holds normalized query text, partitioned by account, for a period measured in minutes. See Section 10 for how a cache hit bills.

Sirveil is an independent business with respect to your account, billing, and abuse-prevention data about you.

Aggregate operational statistics. We may compute and use statistics about how the Service runs — call volumes, latencies, error and refusal rates, capacity and cost — to operate, secure, support, and improve it, and to report on the Service in aggregate. ⛔ This right is limited to operational measurements and does not reach the Identifiers you submit or the Output we return. We do not build a dataset about Subjects, we do not enrich a separate product with your queries, and nothing we publish will identify you or any Subject or make your usage attributable to you.

Service-provider terms. These Terms are the parties' service-provider contract for the purposes of the California Consumer Privacy Act, and no separate addendum is required for Sirveil to act as your service provider. Sirveil:

1. will not sell or share the Identifiers you submit, as "sell" and "share" are defined by the CCPA;
2. will not retain, use, or disclose them for any purpose other than the business purposes specified in these Terms and the API Privacy Notice — namely, answering the call you made and maintaining the billing record described above — including outside the direct business relationship between us;
3. will not combine them with personal information received from any other source, except where the CCPA permits a service provider to do so;
4. will comply with the obligations the CCPA places on a service provider, and will provide the same level of privacy protection the CCPA requires of you;
5. will notify you if Sirveil determines that it can no longer meet those obligations;
6. grants you the right to take reasonable and appropriate steps to confirm that Sirveil uses the Identifiers consistently with your own obligations under the CCPA, and to stop and remediate any unauthorized use — including, on written request, a written description of the measures Sirveil applies; and
7. acknowledges that it understands these restrictions and will comply with them.

Where your own regulator or customer requires a separate addendum on their paper, write to [email protected] and Sirveil will review it.

⭐ The three-state contract. A Verification returns exactly one of three states — indexed, not_indexed, indeterminate — and the Service ships the limits of the method inside every response body, in the contract.limitation field, in these words:

That text is reproduced here so that the contract and the payload cannot drift apart. If the two ever differ, the text the Service returns in the response body is the one that describes the Service.

What follows from it, as commitments about how we report:

• indeterminate means we could not confirm either way. It is not a euphemism for not_indexed, and we will not report it as one.
• An identity submitted with a name and nothing else can never return indexed. A name alone cannot distinguish your subject from everyone who shares the name, so the honest answer is indeterminate, and that is the answer you will get.
• not_indexed is reserved for the case where a name-shaped query actually ran and returned nothing. Where only one narrow query shape could be tried, the answer is indeterminate rather than a clean negative.
• Public indexes change without notice. An Answer describes what we observed when we observed it, and may be wrong or stale by the time you act on it.
• We do not warrant that Output is accurate, complete, or current, and Output is never a determination about a person's character, conduct, or eligibility.
• The Registry changes as sources appear, disappear, and change behavior.
• Every response — including every error response — carries the pipeline, weighting, and calibration version stamps that produced it, so an answer you were given can be traced to the exact logic that produced it.

9.1 Confidence, calibration, and linkage are diagnostics, not determinations

A Verification returns confidence and calibrated_probability. A Scan returns per-field linkage signals and match probabilities. They are returned to explain an answer, not to measure its accuracy, and you must not rely on them as a measure of accuracy.

Stated plainly, because you would otherwise have to take these numbers at face value: the calibration behind calibrated_probability is fitted on a small internal sample with very few positive examples, and the linkage weighting is not calibrated — the artifact carries that fact on its face. Sirveil has not conducted a controlled accuracy study against a customer population and publishes no precision figure for the Service.

Accordingly, you will not (a) present any of these values to a Subject or to any person as a probability or a statement about that person, (b) use one as a threshold or an input in any decision about a person — which Section 7 prohibits in any event — or (c) represent to anyone that a Sirveil number expresses a measured accuracy rate. The parts of an Answer built to be relied on are the state, the evidence, the ordered explanation of what was queried, and the coverage block.

9.2 When an upstream source is unavailable

The Service depends on third-party sources. They fail, rate-limit, and change behavior without telling us.

• Where the search provider is unavailable, a Verification returns indeterminate with an outcome of unserved, and bills you nothing. We will not charge you for the sentence "we were unable to look."
• Where a Scan lane's source is unavailable, the lane is reported in the coverage block as failed or never queried, by name, rather than silently dropped.
• The unavailability, degradation, or behavior change of a third-party source, and any refusal or indeterminate that results, is an operating condition of a retrieval service and is not a breach of these Terms. Section 15 disclaims a warranty of uninterrupted service and Section 24 covers force majeure.

What you pay. Per-call prices are set out in the Rate Card. The Rate Card is not reproduced here so that a price change does not require an amendment; prices in effect when a call is made are the prices for that call.

What bills, and what does not.

Cache hits bill in full, in the specification's own words: "A cache hit is billed and consumes quota exactly like a fresh call. The cache makes a repeat answer consistent, not free." The cache is per-instance and short-lived — currently minutes, not hours — and we may change how it works. What we will not change without notice is the billing rule in this paragraph, which is stated here and in the Documentation rather than discovered on an invoice.

How billing runs. The Service is sold metered. You pay per call, at published rates, for calls that were served. There is no subscription, no minimum, no seat count, no committed spend, and no free trial, and Sirveil publishes no plan ladder for the Service. The Service does contain quota mechanics — an account may be provisioned with a monthly unit budget, and a call that would exceed it is refused with 429 quota_exceeded and bills nothing — but an account purchased through a Marketplace is provisioned without a unit budget. Whatever limits apply to your account are reported to you, free, by GET /api/v1/whoami.

Price changes. We may change the Rate Card on at least 30 days' notice to your account email. Changes apply prospectively only; they never bill retroactively for usage already incurred. Where you purchase through a Marketplace, a price change on that listing also follows the Marketplace's own change and notice process, and the price published on the listing when a call is made is the price for that call.

Metering is the record. Every authenticated call writes exactly one metering row from the Service's own accounting path. That row — not a client-side count — is the billing record. ⏰ We will show you your usage, and we will investigate any discrepancy you report within 90 days of an invoice in good faith and correct genuine errors.

Taxes. Prices exclude taxes. You are responsible for all taxes, duties, levies, and similar charges arising from your purchase other than taxes on Sirveil's net income. Payments are made without deduction or withholding; if withholding is required by law, you will gross up so that Sirveil receives the amount it would have received without the withholding. Where you purchase through a Marketplace, that Marketplace's tax handling applies to the transaction.

If an invoice goes unpaid. An undisputed amount not paid when due accrues interest at the lesser of 1% per month or the maximum the law allows, from the due date until paid, and you will reimburse reasonable costs of collection, including legal fees. We will tell you before we suspend, and Section 18 gives ten days' notice. An amount you dispute in good faith under the 90-day process above does not accrue interest while it is being investigated.

Marketplace billing. If you purchased through a Marketplace, invoicing, payment, refunds, and disputes follow that Marketplace's process, on usage Sirveil reports to it. Your invoice line items read verification and scan.

10.1 What bounds your bill — and what the spend ceiling actually caps

Your bill is bounded by your own call volume, and by a unit quota if your account has been provisioned with one. Nothing else bounds it.

In particular, the per-account protective ceiling described in Section 11.1 is measured against Sirveil's own supplier costs, not against your charges. It exists to stop a runaway integration from costing us money. It is not invoice protection, it does not guarantee your bill stays under any figure, and we will never tell you that it does. If you need a hard spending bound, bound the number of calls your integration is able to make — that is the only control that actually caps a metered bill, and it is on your side of the line.

10.2 No minimum, no volume commitment, no reserved capacity, no exclusivity

• You commit to no volume. If you make no calls, you owe nothing.
• Sirveil reserves no capacity for you and holds no headroom for your traffic. Capacity is shared and subject to Section 11.1. If you need reserved capacity, that is an enterprise agreement, not this one.
• Nothing here is exclusive in either direction. We may serve anyone, including your competitors. You may buy the same capability from anyone else, including while you buy it from us.

We may set and adjust rate limits, concurrency limits, and quotas, and may throttle or queue calls to protect the Service and other customers. Documented limits will be published, and the limits applying to your account are readable at any time, free, from GET /api/v1/whoami. Limits are applied on a best-efforts basis: serving a call that exceeded a published limit does not raise your limit, waive it, or entitle you to that behavior again.

We may add, change, or discontinue features; where a change would materially reduce the Service you are actively paying for, we will give at least 30 days' notice and you may stop using the Service before it takes effect.

Support and availability. No uptime commitment applies to self-serve accounts, and none is offered here. Sirveil publishes no status page or availability metric for the Service, and any monitoring, status, or incident information we may publish or share is provided for information only and is not a service-level commitment. Service-level commitments are available only under a signed enterprise agreement.

11.1 Protective limits, refusals, and what they mean

Four independent bounds can refuse a call. They are checked in a deliberate order so you always receive the most specific and most actionable refusal available:

A suspended account is refused 403 tenant_suspended. A request naming an excluded domain class is refused 403 domain_excluded. A malformed or incomplete request is refused 400. An unavailable retrieval source returns 503 search_unavailable or, on a Verification, an indeterminate answer with an unserved outcome.

A refusal under any of these is a documented limit operating as intended. It is not a breach of these Terms, and it does not entitle you to damages, a credit, or a refund. None of them bills you anything. Where a limit refuses you and you think the limit is wrong for your account, write to [email protected] — that is a conversation, and for most accounts it is a configuration change rather than an argument.

We may label a feature, endpoint, or response field beta, preview, experimental, or evaluation. Anything so labelled is offered as is, for evaluation only, may change or be withdrawn without the notice Section 11 otherwise requires, is excluded from the commitments in Section 15, and should not be relied on in production. Where such a feature bills, it bills at the published rate and the metering warranty in Section 15(a) still applies to it — we will not charge you for a call we did not serve, whatever the feature is called.

Subject to Section 7, to the limits in this Section, and to payment, Sirveil grants you a perpetual, worldwide, non-exclusive, royalty-free license to store, reproduce, modify, create derivative works from, embed, white-label, bundle, display, distribute, and resell the Output, alone or within your own products, at any price you choose, with no revenue share and no additional commercial fee.

Two limits, and they cost an honest customer nothing.

(a) Not for competing use. This license does not extend to using Output to build, train, or enrich a dataset, model, or service that detects, scores, or reports personal-data exposure in competition with the Service, or to replicating the Registry. Sell the answers; do not assemble them into the thing that answers.

(b) Conditioned on the fence. This license is conditioned on your compliance with Section 7 and AUP Section 4. If we give you written notice of a breach of either and you do not cure it within 15 days, this license ends as to Output delivered to you after the date of that notice, whether or not we also terminate the agreement. Section 19 governs Output already delivered where we terminate for a fence breach.

Output may incorporate material sourced from third parties. Sirveil grants only such rights as it holds. We do not represent that reproducing or distributing evidence drawn from a third-party page is permitted by that party, and clearing third-party rights in such material is your responsibility.

This license is limited by Sections 7 and 13 and by the AUP, and by the flow-down obligation in Section 7; use outside those limits is outside the scope of this license. Subject to Section 19, it survives termination as to Output already delivered. Sirveil claims no ownership of your products or of your customers' relationships.

The Service, the Registry, the Documentation, the software, the Sirveil marks, and everything we make available other than Output are owned by Sirveil and licensed to you only as set out here. You get no rights by implication or estoppel; all rights not expressly granted are reserved.

You will not use the Service, the Documentation, or Output to:

1. build, train, or enrich a dataset, model, or service that competes with the Service;
2. replicate the Registry; or
3. conduct benchmarking or competitive analysis for, or on behalf of, a person who offers or is developing a service that competes with the Service.

What this does not restrict. You may evaluate the Service for your own purposes, run your own tests against it, publish your own honest results, and say what you found. We publish comparisons ourselves and we are not going to forbid you from publishing yours. What is out of bounds is doing that work as a competitor's proxy, and copying the thing rather than using it.

Feedback. If you send us ideas or suggestions, we may use them freely, without obligation or compensation, and they are not your confidential information.

Publicity. Neither party will use the other's name or marks publicly without consent, except that Sirveil may identify you as a customer by name and logo in customer lists and on its website; tell us at [email protected] if you would rather we did not, and we will stop.

Each party will protect the other's non-public information disclosed in connection with the Service — including the Rate Card where individually negotiated, security details, subprocessor lists disclosed under Section 6.1, and unreleased roadmap — with at least reasonable care, use it only for the Service, and not disclose it except to personnel and advisers bound to comparable terms. The usual exclusions apply (already known, public through no fault, independently developed, lawfully received). Compelled disclosure is permitted with prompt notice where lawful. Obligations run for three years after disclosure, and indefinitely for trade secrets.

What we commit to — three specific things, and no general one.

⭐ (a) We warrant that we meter honestly. A call is billed only where the Service actually served it. This is not a policy we apply by hand: the metering path computes billable units as the units requested if, and only if, the outcome was served, and zero otherwise, so a non-2xx response, a refusal, a provider failure, and an unserved answer all carry zero billable units by construction rather than by intention. If we ever bill you for a call we did not serve, that is a breach of this warranty and we will correct it.

(b) Published limits and named refusals. The limits that apply to your account are published in the Documentation and readable free from GET /api/v1/whoami, and a refused call returns a named refusal code from the published list rather than a generic error.

(c) Notice before a material reduction. We will give the notice described in Sections 11 and 20 before a change that would materially reduce the Service you are actively paying for.

We give no general warranty of skill, care, workmanship, availability, or performance, and none is to be implied. We have not undertaken a service level, and Section 11 states that no uptime commitment is offered.

You warrant that you hold the Identifiers you submit lawfully, that your use complies with Section 7 and the AUP, and that you have made the disclosures and obtained any consents your own use requires.

Otherwise, the Service and the Output are provided "AS IS" and "AS AVAILABLE." TO THE MAXIMUM EXTENT PERMITTED BY LAW, SIRVEIL DISCLAIMS ALL OTHER WARRANTIES, EXPRESS OR IMPLIED, INCLUDING MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, ACCURACY, AND NON-INFRINGEMENT, AND DOES NOT WARRANT THAT THE SERVICE WILL BE UNINTERRUPTED OR ERROR-FREE OR THAT OUTPUT IS ACCURATE, COMPLETE, OR CURRENT. THIS DISCLAIMER EXTENDS TO ANY WARRANTY ARISING FROM COURSE OF DEALING, COURSE OF PERFORMANCE, OR USAGE OF TRADE, AND TO ANY GUARANTEE, PROMISE, ASSURANCE, OR UNDERTAKING NOT WRITTEN IN SECTION 15(a) TO (c) ABOVE. NO PERSON — INCLUDING ANY EMPLOYEE, AGENT, OR RESELLER OF SIRVEIL — IS AUTHORIZED TO GIVE ONE, AND ANY PURPORTED GUARANTEE OR PROMISE GIVEN OUTSIDE THESE TERMS IS OF NO EFFECT.

Statements on our website and in our marketing about our mission, our roadmap, or the future of personal-data control are made in good faith, are aspirational, and are not warranties or part of this agreement. Latency, throughput, and accuracy figures we publish are measurements of our own runs and are not commitments.

15.1 No certifications, no audit, no penetration test

Stated expressly, so that nothing is implied and so you learn it now rather than in diligence:

Sirveil holds no SOC 2 report, no ISO 27001 certification, and has not had a third-party penetration test. Sirveil holds no other security or privacy certification, attestation, or audit report for the Service, and nothing in these Terms, the Documentation, or our marketing should be read as claiming one.

Data is encrypted in transit and is subject to our platform providers' encryption at rest. Beyond the specific commitments in these Terms and the API Privacy Notice, we make no representation about particular security controls.

If your organization requires a certification, an audit report, or a completed penetration test as a condition of purchase, the answer today is that we do not have one. Ask before you subscribe; we would rather lose the deal in week one than fail your review in month six.

You indemnify us. You will defend, indemnify, and hold harmless Sirveil and its officers, directors, employees, and agents from third-party claims, and resulting damages, losses, and reasonable legal costs, arising from (a) your or your customers' use of the Service or Output in breach of Section 7 or the AUP, (b) Identifiers you submitted without a lawful right to do so, (c) your breach of these Terms or of applicable law, or (d) claims by a Subject arising from your use of Output. We may assume control of the defense at your expense, and you will cooperate.

We indemnify you, and here is the size of it. We will defend you against a third-party claim that the Service, used as documented and within Section 7, infringes that party's US intellectual property, and pay damages finally awarded or amounts we agree in settlement. This does not apply to claims arising from Output content, from Identifiers you supplied, from your modifications or combinations, or from use outside the Documentation or Section 7. If the Service becomes the subject of such a claim, our remedies — and yours — are that we may procure a right to continue, modify the Service, or terminate access and refund prepaid unused fees. Our defense costs, together with any damages or settlement amounts we pay under this paragraph, count against the cap in Section 17(b), and this paragraph is our entire liability for infringement claims.

TO THE MAXIMUM EXTENT PERMITTED BY LAW:

(a) NEITHER PARTY IS LIABLE FOR INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES, OR FOR LOST PROFITS, LOST REVENUE, LOST DATA, OR LOSS OF GOODWILL, EVEN IF ADVISED OF THE POSSIBILITY.

(b) EACH PARTY'S TOTAL AGGREGATE LIABILITY ARISING OUT OF OR RELATING TO THESE TERMS OR THE SERVICE IS LIMITED TO THE GREATER OF (i) THE FEES YOU PAID SIRVEIL FOR THE SERVICE IN THE TWELVE MONTHS BEFORE THE EVENT GIVING RISE TO THE CLAIM, OR (ii) ONE HUNDRED US DOLLARS.

(c) Neither the exclusions in (a) nor the cap in (b) applies to: your payment obligations; your indemnity in Section 16; your breach of Section 7 or the AUP; your breach of Section 14; or either party's fraud or willful misconduct. Sirveil's liability for its own breach of Section 14 remains subject to the cap in (b).

(d) These limits apply regardless of the theory of liability and survive any failure of essential purpose. Nothing here excludes liability that cannot lawfully be excluded.

We may suspend a key, an account, or a Marketplace entitlement immediately, without liability, where we reasonably believe there is a breach of Section 7 or the AUP, a security or fraud risk, a legal requirement, or a threat to the Service or to others; and on ten days' notice where an undisputed invoice is unpaid. Where practicable and lawful we will tell you why and give you a chance to fix it first; where the risk is immediate we may act first and tell you after. A suspended account is refused 403 tenant_suspended. Suspension does not relieve you of fees for Billable Answers already delivered.

These Terms run while you have an account or continue to call the API. You may terminate at any time by closing your account and stopping calls; there is no exit process and no termination fee. We may terminate for material breach not cured within 15 days of notice, immediately for a breach of Section 7 or of AUP Section 4, on 15 days' notice to cure for other AUP breaches, and otherwise on 30 days' notice.

On termination: your right to call the API ends; fees already incurred remain payable; the license in Section 12 continues for Output already delivered; and your data is handled as Section 8 and the API Privacy Notice describe — a pending asynchronous job expires on its ordinary 24-hour clock, and the per-call activity rows described in Section 8(3) are retained as the billing record.

Except where we terminate for breach of the fence. If we terminate for your breach of Section 7 or of AUP Section 4, the license in Section 12 ends as to further reproduction, distribution, and resale; you will stop distributing Output and delete it on request. You may continue using Output already embedded in a delivered product only so far as necessary to avoid harm to a third party, and not to make new copies.

Sections 2, 3, 7 (as to Output retained), 8, 9 (with 9.1 and 9.2), 10 (as to accrued fees, with 10.1 and 10.2), 11.2, 12–17 (with 15.1), and 19–24 survive, together with any provision that by its nature should survive.

We may update these Terms on at least 30 days' notice to your account email. Changes apply prospectively; they never bill retroactively and never narrow the license in Section 12 for Output already delivered. If you do not accept a change, stop using the Service before it takes effect. Continued use after the effective date is acceptance. Each version carries a version number and effective date.

You will comply with applicable export-control, sanctions, and anti-corruption laws, will not export or re-export the Service or Output in violation of them, and will not use the Service on behalf of a restricted party.

US Government end users. The Service and the Documentation are "commercial products" comprising "commercial computer software" and "commercial computer software documentation" as those terms are used in 48 C.F.R. § 2.101. If acquired by or on behalf of the US Government, they are provided with only those rights granted to all other end users under these Terms, in accordance with 48 C.F.R. § 12.212 and 48 C.F.R. §§ 227.7202-1 through 227.7202-4. No other licence, right, or government data right is granted, and any provision inconsistent with this paragraph does not apply.

Step one, mandatory for both sides. Before starting arbitration or any formal proceeding — other than an application for injunctive or emergency relief permitted by the carve-outs below, or a small-claims action — the complaining party will send a written remedy petition — to [email protected] for us, to your account email for you — describing the dispute and the remedy sought. The parties then have 60 days to resolve it in good faith, including at least one call or video conference between people with authority to settle. Limitation periods are tolled for those 60 days.

Step two. Any dispute not resolved that way is finally resolved by binding arbitration administered by the American Arbitration Association under its Commercial Arbitration Rules, before one arbitrator, in English, seated in San Jose, California, with remote hearings available. Judgment may be entered in any court of competent jurisdiction. The Federal Arbitration Act governs this Section.

Individual basis only. CLAIMS ARE ARBITRATED INDIVIDUALLY; NO CLASS, COLLECTIVE, CONSOLIDATED, OR REPRESENTATIVE PROCEEDINGS, AND THE ARBITRATOR MAY NOT CONSOLIDATE CLAIMS.

Bench determination for claims that reach a court. For any claim within the carve-outs below, or any claim otherwise heard by a court: to the extent a pre-dispute waiver of jury trial is enforceable under the governing law, both parties waive trial by jury. Because California does not enforce pre-dispute jury-trial waivers, the parties instead agree that any such claim heard in a California court will be submitted to a referee for a general reference under California Code of Civil Procedure §638(a), the referee to try all issues, whether of fact or of law, and to report a statement of decision on which judgment may be entered. The parties will agree on a referee within 15 days of a written request; failing agreement, the court appoints one. The parties share the referee's fees equally, subject to any award of costs in the final decision. If the general-reference provision is held unenforceable, the claim is tried by the court, and the jury waiver applies only where enforceable.

Carve-outs. Either party may bring a qualifying claim in small-claims court, and either party may seek injunctive relief in court for breach of Section 7, intellectual-property misuse, breach of confidentiality, or security abuse. Emergency and injunctive relief is not subject to the 60-day waiting period in step one.

Time limit. ⏰ Any claim must be brought within one year after it accrues or it is permanently barred, to the extent the law permits. This does not apply to claims for unpaid fees, to Sirveil's claims under Sections 7, 13, or 16, or to a claim that could not reasonably have been discovered within that period — fence breaches and registry misuse routinely surface late, through a regulator or a downstream customer.

California law governs these Terms, without regard to conflicts rules. Subject to Section 22, the state and federal courts in Santa Clara County, California have exclusive jurisdiction. The UN Convention on Contracts for the International Sale of Goods does not apply. The choice of California here is deliberate and is not an oversight against Sirveil's consumer Terms of Service, which specify Delaware. These are different products with different counterparties, and California is the correct law for this one: Sirveil's principal office and the arbitration seat are both in San Jose, Sirveil has been qualified to transact business in California since 16 September 2025, and the general-reference procedure in Section 22 is a California procedure that assumes California venue.

• Assignment. You may not assign these Terms without our written consent; we may assign in connection with a merger, acquisition, or sale of assets. Any other attempted assignment is void.
• Force majeure. Neither party is liable for delay or failure caused by events beyond its reasonable control, including upstream provider outages, network failures, government action, and natural disasters. Payment obligations are not excused.
• Independent contractors. No partnership, joint venture, agency, or employment is created.
• No third-party beneficiaries, except that Sirveil's officers, directors, employees, and agents may enforce Sections 16 and 17; a Marketplace may enforce the provisions required by its own terms; and Sirveil may enforce the Section 7 flow-down restrictions against your customers and their recipients as an intended third-party beneficiary of those contracts.
• Notices. To you, by email to your account address, deemed given when sent. To us, every notice of any kind goes to [email protected] — one monitored channel, deemed given one business day after sending. Put the matter in the subject line so it reaches the right person on the first read: Legal Notice · Privacy · Security · Abuse Report · Remedy Petition. A notice is effective whether or not the subject line is right.
• Severability. An unenforceable provision is reformed to the minimum extent necessary, or severed, and the rest stands.
• No waiver. A delay in enforcing is not a waiver, and no waiver is effective unless written.
• Entire agreement. These Terms with the documents in Section 3 are the whole agreement about the API and supersede every prior or contemporaneous agreement, proposal, quote, demonstration, roadmap, benchmark, blog post, social post, marketing page, sales conversation, and AI-assistant output, whether written or oral, on the same subject.
• ⭐ No reliance on anything outside this agreement. You acknowledge that in deciding to use the Service you have relied only on these Terms and the documents named in Section 3, and on nothing else — including any statement on sirveil.ai, on any marketplace listing, in any specification, benchmark, sample report, calculator, or illustration, or made by any person on Sirveil's behalf. Those materials describe the Service in general terms, are produced for a general audience, and may be incomplete, out of date, or wrong. Where any of them differs from these Terms, these Terms govern, and no such material creates a warranty, a condition, a representation, a guarantee, or a promise of any kind. This paragraph does not limit liability for fraud or for any liability that cannot lawfully be limited.
• Feedback. If you send us suggestions, feature requests, or comments about the Service, you grant us a perpetual, worldwide, royalty-free, irrevocable license to use them without restriction or obligation to you. We will not identify you as the source without your consent.
• Publicity. Neither party will use the other's name, logo, or marks in publicity without prior written consent, except that you may state factually that you use the Service.
• Counterparts and acceptance. These Terms may be accepted electronically, and acceptance by subscribing through a Marketplace or by issuing or using a key is as effective as a signature.
• Interpretation. Headings are convenience only; "including" means "including without limitation"; these Terms are not construed against either party as drafter. The plain-English notes are explanatory only, are not operative, do not enumerate exhaustively, and where a note and the operative text differ, the operative text controls.

Sirveil, Inc., a Delaware corporation · San Jose, California General: [email protected] · Privacy: [email protected] · Security: [email protected] · Support: [email protected] · Remedy petitions: [email protected]

Drafting principle applied throughout this version. Describe generously; warrant narrowly. Every convenience the Service delivers mechanically — unserved calls billing nothing, refusals billing nothing, free whoami and polling, no allowlist, the method's limits printed inside every response — is stated, because a customer should be able to read these Terms and see how favorable the billing is. Each is stated as a description of how the Service operates, not as a warranty of how it will always operate. The single exception is honest metering in Section 15(a), which is structurally enforced in the metering path and cannot silently regress, and which is therefore warranted outright.

Added 25 August 2026 — protective provisions that were absent. Non-reliance (§ 24) · warranty disclaimer extended to course of dealing, usage of trade, and to any guarantee or promise given by any person outside these Terms (§ 15) · feedback licence, publicity, counterparts and electronic acceptance (§ 24) · features offered for evaluation (§ 11.2) · aggregate operational statistics, expressly excluding Identifiers and Output (§ 8) · interest and collection costs on unpaid invoices (§ 10) · suspension on ten days' notice for non-payment (§ 18) · US Government restricted rights (§ 21). All contact is now one channel — [email protected], with subject-line routing (§ 24).

Cross-references. Section numbering in this version is unchanged from the previous one — every new section is a decimal suffix — so cross-references from the Acceptable Use Policy and the API Privacy Notice to Sections 3, 7, 14 and 22 still land.