API and MCP Terms

1Scope#

These API and MCP Terms apply to your use of the Jid REST API (paths beginning /v1), the MCP server (/mcp), monitors and webhook deliveries, the signed JSON statements at /badge, and the public keys at /.well-known/jid-keys.json (together, the "API"). They supplement the Terms of Service and the Permissible Use and FCRA Notice, which also apply. Capitalised terms not defined here have the meaning given in the Terms of Service.

Technical details, including endpoints, fields and current limits, are in the API documentation (/api-docs) and the agent guide (/agents). The documentation describes how the API works; it does not add promises to these terms.

2Access and API keys#

Access without a key. You may call the API and MCP server without a key, within the anonymous limits published in the API documentation (at the date above, 10 requests a minute and 100 a day per IP address). We may change or withdraw access without a key at any time.

Keys. An API key is issued from your Jid account, only after you complete the account profile and accept the certification in the Permissible Use and FCRA Notice. It is free (no payment method, one free key per account) until you add a payment method through Stripe, which upgrades the same key; no new key is issued. The key is shown once when it is issued. We store a cryptographic hash of it and, for keys issued from an account, an encrypted copy that you can display again only after confirming your identity by e-mail. You can rotate a key at any time; the old key stops working at once.

Each paid key is tied to one Stripe subscription. Keys are personal to the customer they are issued to. You may use a key in your own applications and for your own users, but you may not sell, lend or share it with another organisation.

Do not put a key in client-side code, a mobile app, a public repository or a prompt that third parties can read. Send it only in the Authorization header over HTTPS. You are responsible for all calls made with your key until you report it compromised to security@jid.com.

3Rate limits#

Each key has a per-minute and a per-day limit (at the date above, by default 30 requests a minute and 1,000 a day for a free key, and 60 a minute and 10,000 a day for a paid key). Over a limit, the API answers with HTTP 429 and a Retry-After header. We may set different limits for a key, and may lower limits temporarily to protect the service.

You must not evade a limit or the free allowance, including by using several keys or free keys under several e-mail addresses, rotating IP addresses, using proxies or distributing calls across accounts. To ask for higher limits, write to hello@jid.com.

4Free allowance and metered billing#

Billable calls (checks) are those the pricing page (/pricing) describes as billable at the time of the call. At the date above, a check is one keyed read of a file (the file and verify endpoints and their MCP equivalents), and one qualification (the qualify endpoint or the qualify_counterparty MCP tool) counts as 2 checks, and one screen (the screen endpoint or the screen MCP tool, with a key) counts as 1 check; search calls, monitor management calls and anonymous calls are not checks. Monitors are billed per monitored file per month.

Free allowance. At the date above, every key includes 1,000 checks and 100 monitored files a month at no charge. A free key stops serving checks once it has made 1,000 in a calendar month (UTC) until the next month or until a payment method is added, and cannot have more than 100 active monitors. A free key is never charged. On a paid key the allowance applies to each billing month, and checks and monitored files beyond it are charged at the prices on the pricing page (at the date above, from $0.05 a check and $0.05 per monitored file a month, with lower prices at higher volumes). Monitored files are billed on the number of active monitors on the key at the last daily usage report of the billing month.

We record each call in our usage records, report billable usage to Stripe once a day and invoice monthly in arrears. Our usage records determine the amount billed unless you show they are wrong.

We do not intend to bill a call that fails because of an error on our side. If you are billed for one, tell us within 60 days of the invoice and we will credit it.

Calls made by AI agents, scripts, retries and test environments using your key are billable in the same way as any other call.

5Caching and storage of API data#

You may store API responses, subject to these rules:

• Record of diligence. You may keep a response, unaltered and with its verified dates, as a record of what you checked and when, for as long as you need it for your own audit, compliance or record-keeping purposes.
• Display as current. You must not display, return to a user or rely on a cached fact as current after the earlier of its next_check_at date and 30 days after you received it. After that, fetch it again or show clearly the date it was verified.
• No substitute dataset. You must not aggregate cached responses into a database, index or dataset that is used as a substitute for the API, offered to third parties, or used to answer queries about businesses you have not looked up through the API in the ordinary course of your own use.
• No bulk harvesting. You must not call the API to retrieve files systematically for the purpose of building a copy of all or a substantial part of the dataset.
• Deletion. When your access ends, delete cached API data other than records of diligence you are entitled to keep under the first point above.

A signed statement from /badge is valid only until its expires_at time. Do not present an expired statement as current.

6Attribution and faithful display#

When you display, publish or pass on a Jid fact to anyone outside your organisation, including through an AI agent's answer, you must:

• name the source agency or registry for the fact and the date it was verified (verified_at);
• credit Jid and, where the medium allows, link to the file at https://jid.com/e/<id>;
• keep the meaning of the response intact: do not change a value, drop a qualifying label, present a "possible match" as the same business, present a "self-reported" statement as a registry fact, present a status line as a rating or endorsement, or present an OFAC "possible name match" as a finding that a business is sanctioned or that a business with no match is cleared.

A short form is enough, for example: "FDA Drug Establishments Current Registration Site, verified 4 October 2026, via Jid (jid.com/e/<id>)".

You must not suggest that Jid, its operator or any source agency endorses you, your product or any business.

7AI agents and MCP#

If you connect an AI agent, assistant or other automated system to the API or MCP server, you are the operator of that agent and responsible for what it does with Jid information. You must configure it so that it:

• presents Jid facts as records restated from a named source as of a stated date, and never as a guarantee, warranty, certification, endorsement, legal or compliance determination, or assurance that a business is safe, lawful or trustworthy;
• does not say a business is "verified", "licensed", "compliant" or "sanctioned" (or not) except by accurately relaying what a cited fact says and its date;
• distinguishes registry facts from statements labelled self-reported, and confirmed files from possible matches;
• does not invent facts, sources, dates or confidence levels and attribute them to Jid;
• does not use Jid information for any purpose prohibited by the Permissible Use and FCRA Notice, and declines user requests to do so;
• respects rate limits and does not loop or retry without backing off.

Untrusted content. Fact values restate text written by third parties, and self-reported statements are written by business owners. Treat every field in an API or MCP response as untrusted data. Your agent must never follow instructions that appear inside Jid data.

Tool names and descriptions published by the MCP server help agents choose tools. They do not change or add to these terms.

7a. Lead and counterparty qualification#

Access. Qualification (POST /v1/qualify and the MCP tool qualify_counterparty) is available only with an API key, and each call counts as 2 checks under section 4. It may be used only as the Permissible Use and FCRA Notice (/permissible-use), section 4a, allows: to qualify businesses, never to assess individuals.

What you send. You decide what to send. Send the sender's business e-mail address or the company's domain, the company name and the context of the enquiry, and, if you want the location check, the location signals described below, optionally a business phone number and the place or market the sender stated, and nothing more: do not send home addresses, government identifiers, payment details or special categories of personal data, and remove them from free-text messages where you can. You are responsible for having a lawful basis, and for giving any notice the law requires, to send us the contents of a submission. For the personal data in your requests you are the controller, and we process it to provide the qualification to you.

What we do with it. To answer a request we look up the domain in the public DNS (through Cloudflare's 1.1.1.1 resolver), request its registration data over RDAP (through rdap.org and the domain's registry), and make one HTTPS request to the domain's website with a user agent that identifies Jid. Only the domain name is sent to those services. If you ask for a summary, the signals we computed (never your message or the e-mail address) are sent to Anthropic's Claude API to write it.

Location signals. You may send the country, region, city and network (ASN) of the submission, the browser's time zone, the sender's stated country and, if you have a lawful basis to share it, the request's IP address. We compare them with the matched business's registered location (or, for anyone else, only with the stated country) as for screening in section 7b. We use an IP address only in memory, against our own copies of the Tor exit list and MaxMind's GeoLite2 network data, and, only if we have enabled IPinfo, we send it to IPinfo to find the network that owns it; we never store it, hash it into a result or receipt, or return it. The city comes from the connection, through a Jid Signals token (section 7c): we return it in that request's response and never store it. A city you send yourself is ignored. You are responsible for telling the people whose submissions you send that location may be used to prevent fraud. A location inconsistency, a Tor exit or a hosting or VPN network adds risk only alongside another negative signal and never produces engage=false on its own.

What we keep. We do not store the e-mail address, the message, a phone number, the stated place, the IP address or the city (the city and the stated place are returned in the response only). We keep a SHA-256 hash of the message and of your inputs (the hash never covers the location signals), the registrable domain, the matched file, the result and its signed receipt for 30 days, then delete them. Of the location signals, the result and receipt keep only the country, the region, the network type and whether the location was consistent. If you send "retain": true, we also keep the message, and keep the result and receipt for 13 months, as a record you have asked us to hold.

Results. A qualification is produced automatically by the published rules and describes the public records and live checks we read at that moment. It is not a guarantee about a business, not legal advice, and not a credit, employment, insurance or housing decision. Section 6 applies when you show a result to anyone else.

7b. Engage-or-not screening#

Access. Screening (POST or GET /v1/screen, the MCP tool screen and the Jid browser extension) is available without a key within the anonymous limits in section 2 (at the date above, 10 requests a minute and 100 a day per IP address), and with a key, when each call counts as 1 check under section 4. It may be used only as the Permissible Use and FCRA Notice (/permissible-use), section 4b, allows.

What the answer means. A screen returns engage (true or false), a risk level (low, medium, high or unknown), a confidence between 0 and 1, the reasons with their sources, and mitigations. They are produced automatically, without an AI model, by the published screen rules (/screen-rules), which set out the hard rules that always return engage=false and how the policy you choose (strict, balanced or permissive) turns a risk level into engage. A possible name match on a sanctions, export-screening or exclusion list is a prompt for manual review, never a finding.

engage is advisory. You decide whether to engage, and you are responsible for that decision and for any action an AI agent you operate takes on it. A screen is not a warranty that a business, sender or website is genuine or safe, and a listing on a third-party phishing or malware feed is not a finding by us that a host is malicious. The feeds and other sources we read may be incomplete, out of date or wrong, and a check that does not finish in time is reported as not checked.

What you send. Send only the identifiers a screen needs (a domain, URL, e-mail address, phone number or company name, the context and any amount). Do not send special categories of personal data, government identifiers or payment details. A person's name, if you send one, is not looked up. For the personal data in your requests you are the controller, and we process it to provide the screen to you.

What we do with it. We look up the domain in the public DNS (through Cloudflare's 1.1.1.1 resolver), request its registration data over RDAP (through rdap.org and the domain's registry), make one HTTPS request to the website with a user agent that identifies Jid, compare the host with our local copies of phishing and malware feeds, parse the phone number on our own servers, and compare identifiers with the public records we hold. We do not store the e-mail address, phone number or name: the signed receipt keeps the domain, the host, the e-mail's domain, the phone's country, a SHA-256 hash of your inputs and the result for 30 days, or 13 months if you send "retain": true.

Location signals. You may send the country, region and network (ASN) of a request, the browser's time zone, the counterparty's stated country and, if you have a lawful basis to share it, the request's IP address. Send an IP address only if you need the Tor and network check; we use it in memory and do not store it. You are responsible for telling the people whose requests you screen that location may be used to prevent fraud. A location inconsistency, a Tor exit or a hosting or VPN network adds risk only alongside another negative signal and never produces engage=false on its own.

Browser extension. The extension sends only the hostname of the page you are viewing (never the full address or the page's content) and, if you saved one, your API key.

7c. Jid Signals#

What it is. Jid Signals is a script you may place on your pages (https://jid.com/s/1.js) and the endpoint it calls (GET /v1/signal). When a visitor starts or submits one of your forms, the visitor's browser asks us for a token. We read the approximate location (country, region and city) that our hosting provider derives from the connection's IP address, classify the network type (a Tor exit, a hosting or VPN network where we can tell, or unknown) and return a token, signed by us and valid for 30 minutes, that holds those values, the browser's time zone, the host name of your page and a keyed hash of the IP address under a salt that changes every day. The token never contains the IP address. You forward it to /v1/qualify or /v1/screen as signal, with your domain as site, and we use it as the location evidence for that request.

Roles. For Signals we process the visitor's IP address and the location derived from it on your behalf and on your instructions, as your processor (service provider), for the purpose of preventing fraud on your forms. The Privacy Policy (/privacy, section 2) describes this processing to your visitors. We use the IP address only while we make the token and do not store or log it in our application. We do not use Signals data to track anyone across sites, build profiles, or for any purpose of our own except security and abuse prevention of the endpoint itself.

Your obligations. If you use Signals you must (a) disclose it in your own privacy notice before you place the script, in words at least as clear as: "Forms on this site use Jid Signals, which reads your approximate location and network type from your connection to help prevent fraud; your IP address is not stored."; (b) have a lawful basis for the processing, which for fraud prevention is normally legitimate interests, and honour objections where the law requires; (c) use it only on forms where location helps prevent fraud or abuse, and not to make decisions about an individual's credit, employment, insurance, housing or other eligibility (Permissible Use and FCRA Notice); and (d) not send us the visitor's IP address or city yourself when you send a token.

Tokens. A token that is expired, altered or issued to a website other than the site you name is reported as skipped and is never treated as a negative signal. Do not store tokens beyond the form submission, share them with third parties, or try to decode or alter them; their contents may change without notice.

Limits. The script sets no cookies and uses no local storage, and the endpoint is rate-limited per IP address. We may change the token format, withdraw the endpoint or block abusive use under section 11.

7d. Community reports#

What you can do. For a qualification your key ran, you may mark the sender legit (a real business with a genuine enquiry), sales pitch (real, but unsolicited marketing), spam (junk, bots, mass mail) or scam / malicious (phishing, impersonation, a fraud attempt), by a signed link in a notification e-mail, from your account, or with POST /v1/outcomes. Your latest report on a sender replaces your earlier ones. All of one customer's keys, and all the sites one customer operates, report as one organisation.

Your promises. Report honestly and in good faith, about the enquiry you received, and only from your own experience of it. Do not report to harm a competitor, to retaliate, or on behalf of anyone else, and do not create accounts or keys to multiply reports. Reports are about businesses: do not use them to describe or judge an individual. A note you add is private; do not put anyone's personal details in it, and do not write anything you know to be untrue.

Your responsibility. A report is your statement, not Jid's. You grant us the licence to use it described in the Terms of Service (section 11), and you will indemnify us under the Terms of Service (section 10) for any claim that arises from a report you make in breach of this section. We do not pay for reports. We do not tell a reported business who reported it unless the law requires us to, for example under a court order, in which case we will tell you first where the law allows.

What we do with them. We weight each report by the reporter's trust and by its agreement with other reporters, decay it over 12 months, rate-limit it, and use it only as described in the Privacy Policy (/privacy, section 2b): a "community reports" check once at least two independent organisations agree, factual counts on the business's file once at least two independent businesses other than the operator's own sites agree, and our own abuse review. We may discount, remove or refuse reports that look coordinated, false or retaliatory, remove reports under the Disputes and Corrections Policy (/disputes), and suspend reporting for a key that abuses it.

7e. Data processing terms#

This section is the data processing agreement between you and us for the personal data in the requests you send to qualification, screening and the e-mail authenticity check, and for Jid Signals on your pages (the "customer data"). It applies automatically; you do not need to sign anything. If you need a signed copy, or one on your own form, write to privacy@jid.com.

1. Roles and instructions. You are the controller (a "business" under the CCPA) and we are your processor (a "service provider"). Your instructions are these terms and your API calls. We process customer data only to answer your requests as these terms describe, to secure the service and prevent abuse, and to keep the business-level records set out in the Privacy Policy (a company domain associated with a business file, and community reports you choose to make), and for the network signal in section 7f, and not for any other purpose of our own.
2. No sale, no combining. We do not sell or share customer data, retain, use or disclose it outside our direct business relationship with you, or combine it with personal data we receive from others, except as the CCPA allows a service provider to do, including to protect against malicious, deceptive, fraudulent or illegal activity (the network signal, section 7f).
3. Confidentiality and security. Only people and services that need customer data to run Jid can access it, under a duty of confidentiality. We apply the measures on the Security page (/security).
4. Subprocessors. You authorise the subprocessors on the Subprocessors page (/subprocessors). We will update that page before a new one starts processing customer data; if you object on reasonable data protection grounds, tell us and, if we cannot resolve it, you may stop using the affected feature.
5. Assistance. We will help you, taking into account what we hold (mostly hashes and domains), to answer data subject requests and to carry out data protection impact assessments, and tell you without undue delay, and within 72 hours where we can, after we become aware of a personal data breach affecting customer data.
6. Deletion. Customer data is deleted on the schedule in the Privacy Policy (section 5), and in any case when you ask, unless the law requires us to keep it.
7. Information and audits. We will make available the information reasonably needed to show compliance with this section, and answer a reasonable written audit questionnaire once a year.
8. Stored leads. If your account switches on "Keep my leads in Jid" (on by default for accounts created from 9 October 2026, and switchable off at any time), we also store, on your instructions, the leads you send us (a lead block on /v1/qualify, your form webhook, the WordPress plugin or our client libraries) with their Jid read. Purpose: only to show them to you and the teammates you invite in your inbox, to let you work them (status, rating, note, tags), to export them, and to send them to the webhook or HubSpot account you connect; never to build profiles of individuals, to train models, or for any purpose of our own, and the Permissible Use and FCRA Notice still applies to them: they are business leads, not consumer reports. Security: the name, e-mail address, phone number and message are encrypted in our application with AES-256-GCM under a key held outside the database, and the e-mail address is searchable only through a keyed hash scoped to your account. Retention: 90 days, 1 year or 2 years from receipt, as you choose (1 year if you do not); a shorter choice applies to leads already stored. Deletion: you or an admin can delete one lead or all leads at any time; switching storage off stops new storage; on account closure we delete them within 30 days. Export: you or an admin can export them at any time as CSV or through GET /v1/leads; viewers cannot. Subprocessors: the stored leads are held by Vercel (hosting) and Neon (database) and processed by GitHub (the scheduled retry and deletion jobs), all on the Subprocessors page; a webhook endpoint or HubSpot account you connect is your own destination, not our subprocessor, and you are responsible for it.
9. Transfers. Customer data is processed in the United States. Where the GDPR or UK GDPR applies, the European Commission's Standard Contractual Clauses (module two, controller to processor, or module three where you are yourself a processor) and the UK Addendum are incorporated into these terms by reference, with Ireland as the governing law and courts for the clauses and the information in this section completing their annexes.

7f. Network signal#

Your submissions contribute. Each qualification, screening and e-mail authenticity check you make with an API key, from an account on a business e-mail domain, contributes to Jid's network signal in anonymised and aggregated form: we keep keyed hashes (never the values) of the sender's e-mail address, business domain, phone number, the company name given and the daily Jid Signals connection hash, a masked fingerprint of the message, a keyed hash of your organisation, the recommendation and the time, for 90 days, as the Privacy Policy describes (/privacy, section 2c). For this purpose we act as a controller, for fraud prevention.

What you receive. When what you check matches activity seen at 3 or more OTHER businesses, the read includes a "network" check and a "Network activity" line with counts only, for example "This message text was sent to 12 other businesses' forms this week (seen across Jid's network)". We never tell you which businesses, never show a count of 1 or 2, never count your own checks towards your own signal, and never tell any other customer that you checked anything. All the sites one customer operates count as one business; the operator's own sites count as one.

How it decides. It is a warning by default (verify first). It can contribute to "do not engage" only for a strong pattern (the same message from 10 or more senders at 5 or more businesses in 7 days) together with another negative finding in the same read. It describes submission activity, not a person: do not use it, alone or with other data, to make any decision about an individual of the kind the Permissible Use and FCRA Notice prohibits (/permissible-use), and do not try to learn from it what another customer received.

Opting out. A customer on an enterprise agreement may ask us (privacy@jid.com) to opt out. An opted-out account's checks are not recorded, and it does not receive the network signal either. Checks made without an API key are never recorded and never receive it.

8Monitors and webhooks#

A monitor sends you the events recorded on a file (the kind of change, the predicate, the old and new values, the source and the date) by HTTPS webhook, e-mail or both. Deliveries are made after our scheduled re-check jobs run, not in real time, and depend on each source's own publishing schedule.

Each webhook is signed with the monitor's secret (the Jid-Signature header). You must verify the signature and timestamp before acting on a delivery, and keep the secret confidential. A delivery that fails is retried on later runs, but we do not guarantee delivery, order or timing, and we may disable a monitor whose endpoint keeps failing.

You may only direct e-mail notifications to addresses you are authorised to use, and webhooks to endpoints you control. There is a limit on active monitors per key (at the date above, 100 for a free key and 10,000 for a paid key).

9Signed statements#

Statements at /badge/<id>.json are signed with Ed25519. The public keys are published at /.well-known/jid-keys.json, identified by key id. A valid signature shows that Jid issued that statement, with that content, at its issued_at time. It does not show that the facts summarised are true, complete or still current, and it is not a certificate, licence or endorsement.

We may rotate signing keys. We will keep a retired public key published for at least as long as statements signed with it remain unexpired.

10Changes to the API#

The API is versioned. We may add endpoints, fields, predicates and sources at any time; your integration should ignore fields it does not recognise. We aim to give at least 30 days' notice by e-mail to key holders before a change that removes or incompatibly changes a documented field or endpoint in the current version, except where a faster change is needed for security, legal or source-availability reasons.

11Suspension#

We may suspend or throttle a key, an IP address or a monitor immediately, with notice where practicable, if we reasonably believe that it is compromised; that it is being used in breach of these terms, the Terms of Service, the Permissible Use and FCRA Notice or the Acceptable Use Policy; that its use threatens the security, integrity or availability of the service or a source; that an invoice is unpaid; or that the law requires it. We will restore access once the cause is resolved, if it can be.

12No service level#

Unless a signed order form states a service level, we make no commitment about availability, uptime, latency, throughput, the freshness of any fact, the frequency of any re-check, the timeliness of any monitor delivery, or the continued availability of any source. Re-check cadences and next-check dates are targets. Where an order form states a service level, the remedies it sets out are your sole remedies for failing it.

13Termination#

You may cancel a paid key at any time by writing to hello@jid.com from the e-mail address on the key, or through any Stripe billing page we make available; when the subscription ends the key returns to the free allowance, unless it ended because an invoice was not paid, in which case we may suspend the key. You may stop using a free key at any time, and ask us to revoke it. On termination, delete cached API data as section 5 requires and stop using the API with that key. Sections 4 (for amounts owed), 5, 6 and 9 survive.