Where does my token live?
Browser memory
Trust & Security
You're about to point a free tool at an org you're responsible for. Here is exactly what OrgKit can see, store, and do — and what it can't.
Where does my metadata go?
Nowhere
What do you log?
Nothing
Architecture: direct by default, nothing stored ever
OrgKit is a set of static pages. There is no database and no server-side storage of any kind. By default, your browser talks directly to your Salesforce instance over HTTPS using Salesforce's own APIs. That's why each org needs a one-time CORS allowlist entry — Salesforce is verifying that your org's admin approved this site to make browser calls, which is a security feature, not a workaround.
Default
Every API call goes straight from your browser to your org. The access token lives in sessionStorage and is sent only to the Salesforce host you connected to.
Opt-in only
Only routes here if you explicitly click "Use OrgKit relay" (typically when an org hasn't set up CORS yet). It's a stateless pass-through — the token transits it and is gone the instant the response returns. No logs, no storage, no analytics.
Never happens
There is no database and no server-side storage anywhere in OrgKit — this isn't a policy promise, it's the architecture. There is nowhere for your data to go even if something wanted to send it.
The optional relay
If an org hasn't set up CORS, the tools offer a one-click alternative: "Use OrgKit relay." It is off unless you click it. When on, that org's API calls route through orgkit.dev/relay, which forwards each request to your Salesforce instance and returns the response. The relay is a stateless pass-through: no logging, no storage, no analytics — your token and metadata transit it and are gone the moment the response returns. It can only target *.salesforce.com / *.force.com hosts, so it cannot be used as a general proxy. The relay's full source is in the public repo (worker.js, ~50 lines). Prefer the strictest posture? Don't click it — set up CORS once and stay fully direct.
OrgKit works on the metadata layer only — automations, object schemas, profiles, OmniStudio components. It never queries or writes your business records.
Your access token
- You authenticate on Salesforce's own login page (OAuth 2.0). Your username and password never pass through OrgKit.
- The access token is kept in
sessionStorageonly — it is destroyed when the tab closes and is never written to persistent storage. - By default the token is only ever sent to one place: your own Salesforce instance URL. If you explicitly enable the relay for an org, it also transits the OrgKit relay — forwarded, never stored.
- Disconnect any time — or revoke the session in Salesforce under Setup → Session Management.
- Prefer full control? Create your own Connected App in your org and use its Consumer Key instead of OrgKit's shared one. Your admin then controls scopes, IP ranges, and session policies.
What stays in your browser
So that snapshots and audit trails survive a browser restart, OrgKit keeps non-sensitive working data in your browser's localStorage: org nickname and instance URL, automation snapshots, your local audit log, and preferences. None of it contains credentials, and none of it ever leaves your machine. Clearing site data removes everything.
Safety rails for destructive actions
- Snapshot before change — Migration Mode auto-snapshots the exact active/inactive state of every automation before touching anything.
- Verified toggles — after every change, the tool re-reads Salesforce to confirm the change actually applied. Silent failures are surfaced, not swallowed.
- Crash-safe bulk operations — bulk changes are journaled locally item-by-item. If your tab crashes or your session expires mid-run, you can resume exactly where you stopped after reconnecting.
- Production friction — entering Migration Mode on a production org requires typing the org name to confirm.
- Audit log — every change is recorded locally with timestamps and before/after state, exportable to CSV for your change ticket.
Common security-review questions
Is my password stored anywhere?
No. Login happens on salesforce.com via OAuth. OrgKit only ever receives a short-lived access token.
Do you use analytics or tracking?
Cloudflare Web Analytics — privacy-friendly, cookie-free page-view counts, not identities. Never any org data, metadata, tokens, or Salesforce responses.
What scopes does the shared Connected App request?
API access sufficient for the Tooling and REST API calls the tools make. If your policy requires narrower control, use your own Connected App — every tool supports it.
Can OrgKit modify my org without me?
No. There are no stored credentials and nothing that can act on your behalf — even the optional relay only forwards requests your browser makes in the moment. Every change happens live, from your browser, in your session, and is written to the local audit log.
Does the relay see my token?
Only if you enable it, and only in transit: each request carries the token to be forwarded to your Salesforce instance, and nothing is retained — no logs, no storage. The relay is ~50 lines of auditable source (worker.js) and can only reach *.salesforce.com / *.force.com hosts.
Is the code auditable?
Everything is unminified — View Source shows you everything that runs. Each tool is one HTML file plus a small shared CSS and JavaScript pair served from this domain. No bundlers, no build step, no third-party JavaScript dependencies.
Privacy
The full privacy policy covers both the web tools and the Chrome extension — including why the extension requests the cookies permission and what it does with your Salesforce session.
Terms of use
OrgKit is provided free of charge, "AS IS" and without warranty of any kind, express or implied, including but not limited to warranties of merchantability, fitness for a particular purpose, and non-infringement. In no event shall the author be liable for any claim, damages, or other liability arising from the use of these tools.
You are solely responsible for: changes made to any Salesforce org through these tools; compliance with your organization's and your clients' change-management, security, and access policies; and verifying results after any operation. Test in a sandbox before using in production.
OrgKit is an independent project by Himadeep Guduru. It is not affiliated with, endorsed by, or supported by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.
Found a security issue?
Please report it privately via GitHub — responsible disclosure is appreciated and acknowledged.