SECURITY

No patient data.

InPlan holds provider and plan data only. A request carries your API key, an NPI and a plan ID. Nothing about a patient is sent to us or stored.

Report a security issue See our controls

What travels to InPlan, and what never does: your app sends an API key, an NPI and a plan ID to the InPlan API, which holds provider and plan data only and returns an answer with evidence (listed or not found, source, tier, plan year and the read-on date). Patient data sits outside the flow: never sent, never stored.

What we hold.

Three kinds of data, all about providers, plans and your account.

PROVIDER DATANames, specialties, practice locations and identifiers from national provider registries.

PLAN DATAPlans, network tiers and the providers each plan lists, from the network directories that insurers publish. Every row keeps the date it was read.

YOUR ACCOUNTYour name, work email and company, a one-way hash of each API key, and a record of each API call made with your keys.

How your access is protected.

The controls that apply to every account, on every plan, from the first call.

TLS 1.2+Every request to the API and the dashboard is encrypted in transit with TLS 1.2 or later.

KEYS HASHEDWe store a one-way hash of each API key, never the key itself. You see the full key once, when you create it.

RATE LIMITSEach key has its own rate limit. Every response carries rate-limit headers, so your code can pace itself.

READ-ONLYAPI keys read data. No endpoint lets a key change provider or plan records.

REQUEST IDSEvery response carries a request ID. We keep audit logs of API calls and account changes, so any answer can be traced.

Where answers come from.

From the network directories that insurers publish, combined with national provider registries. Each answer shows its source type and the date the data was read.

01You sendYour API key, an NPI and, for a check, a plan ID.GET /v1/check?npi=…&plan_id=…

02We readProvider and plan data we already hold. Nothing is fetched about a person.read-only access

03You getThe answer, its evidence and a request ID you can quote to us."request_id": "req_7f3a2c"

RESPONSIBLE DISCLOSURE

Found a security issue? Tell us first.

Email [email protected] with "Security" in the subject line. We read every report.

Email [email protected]

01Describe what you found and the steps to reproduce it.
02Include request IDs, times and the endpoint, if you have them.
03Use only your own account and keys while you test.
04Give us time to fix the issue before you share details in public.

Questions security teams ask.

Do you handle patient data?

No. InPlan holds provider and plan data only. No patient information is sent to us or stored.

What does a request contain?

Your API key in the Authorization header, an NPI, and a plan ID when you check a pair. A batch call carries a list of NPI and plan ID pairs.

Can you show us the full key we lost?

No. We keep only a hash of each key, so nobody at InPlan can read it. Rotate the key in your dashboard and use the new one.

How do we trace one answer?