1. What rinkats is
rinkats is recruitment-agency management software. Your organisation's records — candidates, requirements, interviews, placements, and everything your team writes about them — belong to your organisation. We operate the software; we do not become the owner of what you put into it.
2. Accounts, roles, and who must accept these terms
Every person who signs in — not just the person who opened the organisation — holds one or more roles: admin, lead, recruiter, billing, or interviewer. Each of those roles must accept these terms individually, in their own name, before continuing to use rinkats; an administrator accepting on behalf of the organisation does not accept on behalf of the people who work in it.
Candidates are the one exception. A candidate applies to a role through a public page that deliberately asks for no account and no sign-in — gating it behind an accept screen would cost an organisation a real candidate over a document that candidate never had reason to see. What we do with a candidate's data is instead covered in §7, and it is the hiring organisation's responsibility, as the data fiduciary, to have told that candidate what happens to their application.
When you add someone to your organisation, they see these terms — and must accept them — the first time they sign in, whatever the date on this document says.
3. Acceptable use
You may use rinkats to run recruitment work for your organisation. You may not: use it to store or process data you are not authorised to hold; attempt to access another organisation's data; attempt to disable, bypass, or overwhelm the platform's security, rate limits, or usage caps; upload content designed to manipulate the AI features (see §4) into taking actions outside what you asked for; or resell rinkats access to a third party without a separate agreement with us.
4. AI features: how they work, and what they cost
rinkats uses AI to parse resumes, draft outreach, screen candidates, and similar tasks. Every one of those tasks produces output you review before it becomes candidate-visible or pipeline-affecting — the product never lets an AI draft act on your pipeline by itself.
Who provides the AI. Your organisation may connect its own API keys for the model providers it prefers (Google Gemini and Vertex AI, Anthropic, OpenAI, DeepSeek, xAI, Mistral, Qwen, or another OpenAI-compatible provider). Where no organisation or user key is configured, rinkats falls back to its own platform key so the feature still works; that fallback usage is metered against our own budget and is not billed to you beyond your plan's normal allowance. A separate provider, Voyage AI, is used only for one step — ranking already-matched candidates against a requirement — under the same per-organisation key arrangement. Nothing you upload is contributed to any provider's model training; the providers process your request and return an answer, under their own terms as the operator of the key in use.
Untrusted content stays data, never instructions. Resumes and any other content someone outside your organisation supplies are scanned by an automatic classifier before any AI model sees them, and are always presented to the model as material to read, never as commands it should follow — this is a fixed rule of the product, not a setting.
Usage caps. All plans give access to the same features today; what differs between plans is how much AI you can run and how many emails you can send before you are asked to upgrade or wait for the next period. Specific figures live in your plan, not in this document, because they change more often than this document should. What does not change: when a cap is close, you are told before you hit it, and when you hit it, the feature that would exceed it pauses rather than running you a bill you did not expect.
5. What we monitor, and why
This section exists because you asked us to write it down, in full, rather than let you find out piece by piece. Everything below is something rinkats staff can already see today, through our internal operating console; none of it is new because this document exists.
- AI usage. Every AI call your organisation makes is recorded — which feature triggered it, which model answered, how many tokens it used, what it cost, how long it took, and which person in your organisation triggered it (or that nobody did, for a scheduled job). Your own administrators can see this for your organisation; rinkats staff can see it across every organisation, to keep the AI budget honest and to know where the product is slow, expensive, or wrong.
- Email and messaging delivery. Every email rinkats sends on your organisation's behalf is logged — who it went to, which template it was, whether it was delivered, bounced, or failed, and why. We use this to enforce the sending cap in §4, to tell you when mail to a candidate or client is not landing, and to keep our own sending reputation clean so your mail keeps landing too.
- Errors. When something in rinkats fails — a resume that will not parse, an AI call that errors out, an API request that 500s — the failure is captured with enough detail for us to fix it, and reviewed by our team daily.
- Feature and product usage, in aggregate. We look at which features get used, by which kind of organisation, and how that changes over time — signups by role, plans bought and cancelled, which AI features run most — to decide what to build next and what to fix first. This is studied in aggregate and by organisation, not by reading your private records for their content.
- Administrative actions on your account. When rinkats staff take an action that touches your organisation — a support fix, a plan change, a refund, publishing a document like this one — that action is logged with the staff member's identity, the time, and (for security) the IP address and browser the action came from. This log is internal; it is never shown to any organisation, including yours.
- What we do not do. We do not read your organisation's candidate pipeline, client records, or private notes for their content as part of this monitoring. We do not sell any of the data described in this section, and we do not show one organisation's data to another. Staff access to the content of your records (as opposed to the metadata above) happens only to provide support you asked for, to investigate suspected abuse or a breach of §3, or where the law requires it.
6. Resumes, and improving the product from them
We use the documents your organisation uploads to improve rinkats itself — principally the resume reader, and the other automated reads built on top of it. The specific mechanism, what we do, what we never do, and how an organisation turns it off, is written out in full in docs/legal/terms-data-use.md (published at /legal/data-use) and is incorporated into these terms by that reference.
In short: when our reader gets a document wrong, we may pull that document, on a machine we control, to reproduce and fix the failure; once fixed, the original is turned into a synthetic test with invented people and the original is deleted. We never sell your data, never show one organisation's documents to another, and never hand your files to a third party to train their model. Your organisation agreed to take part when it was opened (it is a required step of creating an organisation), and can ask us to turn it off at any time.
7. Candidate data
A candidate's data enters rinkats through your organisation, and your organisation remains the data fiduciary for it under India's Digital Personal Data Protection Act, 2023 — rinkats acts as your data processor, handling it under your instructions and these terms. A candidate who asks your organisation to remove their data should have that request honoured; a document that has already been turned into a synthetic test under §6 carries no real identity left to remove.
8. Data retention and deletion
Your organisation's operational records (candidates, requirements, interviews, placements) are kept for as long as your organisation's account is active, plus a limited period after closure to handle billing, legal, and support obligations. Resumes pulled under §6 for parser improvement are retained only until the synthetic fixture is produced, then deleted; the synthetic fixture itself carries no real person's data.
9. Fees, plans, and AI allowances
Fees and plan terms are set out where you bought your plan, not here. One clause about how AI allowances are priced belongs here because it is a promise about currency, not about a price:
AI allowances and credits are denominated in rupees. Because the underlying AI services are priced in US dollars, each plan and each parcel of credit converts rupees to dollars once — at a conversion rate fixed at the moment it is issued — and is then spent at that fixed rate for its whole life, whatever the rupee does afterwards. Two organisations paying the same rupee price at different times may therefore hold different dollar amounts of AI, and neither one's allowance shrinks because the rupee weakened.
rinkats carries that currency risk, and it is not unlimited. On reasonable market or foreign-exchange movement, rinkats may adjust the credit value of a plan, with notice to the organisation's administrator stating what changed and why. Any such adjustment applies to allowances issued after it: credit already issued to your organisation keeps the rate and the rules it was issued under until it is spent or expires. No adjustment is ever automatic — a human reviews it before anything changes.
Full reasoning: docs/legal/terms-ai-credits.md (not a hyperlink here).
10. Security
Resumes and other uploaded files are scanned for malicious content before they are processed. Provider API keys your organisation supplies are encrypted at rest. Access to your organisation's data within rinkats is scoped to your organisation by construction — every internal query carries an explicit check for which organisation it may touch.
11. Changes to these terms
We may publish a new version of this document. If a new version applies to your role, you will see a notice the next time you sign in, and — for a change we mark as requiring it — you will be asked to accept the new version before continuing to use the features it names.
12. Termination
Either you or we may close your organisation's account as set out in your plan's own terms. On closure, §8 governs what happens to your data.
13. Limitation of liability
Placeholder — owner and lawyer to set: liability cap, disclaimer of warranties, indemnity. Not drafted here because it needs a figure and a jurisdiction, neither of which the product decides.
14. Governing law
Placeholder — owner to confirm the governing law and courts. India is the working assumption given the DPDP Act reference in §7, but the entity name, registered address, and jurisdiction have not been set anywhere in the product yet.
15. Contact
Questions about these terms, or a request under §7 or §8, can be sent to support@rinkats.com — placeholder, confirm this address exists before publishing.