What You Can Build With the ClinikEHR API in Nigeria: Ideas by Access Level (2027)

You are a developer or founder in Nigeria looking for health tech startup ideas that run on clinic software. The ClinikEHR API (api.clinikehr.com) lets your software work with a connected clinic's ClinikEHR account, but only as far as that clinic agrees. ClinikAPI (clinikapi.com) is a separate product built around the FHIR health data standard, with its own site, keys and licence. This guide sorts eight ideas by access level and says what each one cannot do.

Quick Answer

Choose your idea by the data it needs, because the data decides who must say yes before your code touches a real clinic.

• Practise first: a test key reaches a sandbox of invented data, never a real clinic. The insurance routes have no sandbox data.
• No patient data (levels 2 and 3): a stock badge, a stock report from another till, a medicine-code mapper and an expiry watch.
• Patient data (levels 4 and 5): a booking tool, a pre-visit form and a referral sender. An organization sees linked patients only.
• Insurer data (level 6): a console for an HMO (health maintenance organization), with two Enterprise requirements, a reviewer's approval and the clinic's link.
• Skip what cannot be built, such as a bill estimator from HMO price lists.

What an Access Level Is, in Plain Words

An access level is how much permission stands between your code and a clinic's data. An API is a set of requests one program sends to another. A key is the secret your program sends with each request. A scope is a named permission on a key, such as reading stock levels.

A clinic's own key reaches that one clinic. An organization's key, made in the developer portal, reaches every clinic that approved a connection to your workspace. A connection starts with a one-time code from the clinic's owner. A sandbox is a practice area of invented data. An HMO pays part of its members' hospital bills.

The Six Access Levels at a Glance

Higher levels need more yeses. The ideas in the last column are illustrative. The documentation states no timeline for any approval, so this guide gives none.

Levels 2 and 3 carry no patient information. Levels 4 to 6 do. Level 1 is a way to practise, not a class of access.

Level 1: Start With a Test Key

What to do. Create a test key in the developer portal. It starts with ehr_test_, comes at once and needs no verification. Test keys are free.

What you need. An account in the developer portal.

A test key reaches only your workspace's sandbox, a fictional clinic seeded with invented inventory, pharmacies, patients, notes, appointments and medicine codes. It never reaches a real clinic. A clinic's own key has no test mode and is always live.

Two limits matter. The insurance routes have no sandbox data: lists answer an empty page, and reads and writes answer 404. You try them with a live key on a clinic that linked you. Also, the documentation describes no sandbox for the stock-report route.

How you know it worked. Your first read answers with invented data.

The mistake people make. Reading a clean sandbox run as proof that a real clinic will say yes.

Who Says Yes: The Approval Model

One rule from the API terms sits under every idea.

Every request is checked against the permissions on your key, the permissions the clinic granted, what the clinic's plan includes, and your plan. If any of them does not allow it, the request is refused.

ClinikEHR API Terms of Use

Records belong to the clinics that made them. A clinic decides whether to connect to you and what to grant, and it may narrow or withdraw that at any time.

The Order of Yeses for an Organization

Steps 1 to 3 and step 6 apply to every organization. Steps 4 and 5 add patient data.

1. Prove you are a real business. Publish a DNS record, which is a text entry in your domain's settings, complete a business profile and submit it for review.
2. An Owner or administrator of your workspace accepts the API Terms of Use, which include the Acceptable Use Policy.
3. ClinikEHR sets a paid plan on request. There is no self-serve checkout. Essential covers non-patient data only.
4. For patient data only, a ClinikEHR reviewer approves each kind of data you applied for. It may approve fewer than you asked for, and it checks again on every request.
5. For patient data only, your workspace Owner accepts the data-protection addendum, version 2026-10-09, between Bettar Platforms, Inc. and your organization.
6. The clinic says yes last, and for itself. Its owner hands you a one-time connection code, ticks only the scopes to grant, records a legal basis where patient data is granted, and approves with a fresh second-factor sign-in. For patient data, the clinic must also be on its Enterprise plan.

A clinic's own key is shorter. An owner, manager, developer, CTO or a staff member with the API access permission switches API access on. It is off by default. They create the key, pick its scopes and set an end date at most 12 months away. For patient records the clinic also needs the API add-on or an Enterprise contract, and its owner accepts the API data agreement. Whoever makes the key signs in with a second factor first. Building for one clinic? Ask the owner to create a key under Settings, API access and share it over a channel you both trust.

Linked Patients Only

An organization's key sees only the patients linked to its connection. A patient who is not linked, a patient the clinic restricted and a patient who does not exist all answer the same 404.

Clinician Review of Anything Written to the Chart

Allergies, conditions, reported medicines and referrals that you send do not change the chart. A person at the clinic decides, and clinical items need a clinician, or the clinic's manager or owner. The reply 202 means received, not yet applied.

Do not treat a 202 as a record that now exists on the chart.

ClinikEHR API documentation, reviewing outside submissions

A clinic may choose automatic acceptance, for one key or one connected organization, and for each kind separately. You cannot ask for it or see whether it is on. Changes, retractions and "no known allergies" statements are never accepted that way.

The Disclosure Record

ClinikEHR records every disclosure of patient information to your organization: which patient, which kind of record, when, and under which connection and basis. It keeps these records for seven years. The patient can see in the clinic's patient portal which organizations received their information, when and what kind, but never the information itself.

What You May Do With It

You receive patient information as an independent controller, for the purpose the clinic agreed to and no other. Ask for the least that serves it. The Acceptable Use Policy bars selling patient information and advertising with it. It also bars building a profile of a person for a purpose the clinic did not agree to. It bars combining the data with other data to identify someone you were not told about, and denying someone care, cover or a medicine by machine alone. A flag from the API is a signal, never a verdict.

The addendum has terms for the Nigeria Data Protection Act (NDPA). An organization in Nigeria, or handling the information of people in Nigeria, is a data controller for what it receives. It is a contract, not a certificate, and this guide is not legal advice.

What the Documentation Does Not Say

The documentation does not say that a patient is asked to consent to each connection. Before patient data flows, the clinic records the legal basis, which is one of four: treatment, payment or health-care operations; a business associate agreement; patient authorization; or de-identified information. The clinic decides which applies, and this guide does not advise on that choice.

Ideas That Need No Patient-Data Approval (Levels 2 and 3)

These four ideas touch stock, listings and codes, so no patient-data approval applies. You still need a key, and the clinic still decides.

At level 2 the pharmacy makes its own key, on a plan with API access, and shares it. At level 3 you use an organization's live key on the Essential plan, which covers non-patient data only, and each pharmacy approves a connection that grants the scope. Reading a clinic's own data, such as its stock, also needs that clinic on a Team-level or higher plan (Business on the Pharmacy and Diagnostics editions). Otherwise the call is refused with plan_required. Two things need less than that. A pharmacy on any paid plan can be listed on the network, and the stock report in Idea 2 works on any paid pharmacy plan.

Idea 1: Show Whether a Medicine Is in Stock

The idea. Show whether a medicine is in stock at one pharmacy, or which listed pharmacies have it, as a band with the time it was last known to be true. It suits a pharmacy's own developer or a patient-app team.

This is the documentation's sample response. A real call needs a live key and a pharmacy that approved your connection, or the pharmacy's own key.

{
  "data": [
    { "item_id": "item_01example", "matched": true, "band": "in_stock", "as_of": "2026-09-27T09:02:11Z" },
    { "item_id": "item_02example", "matched": true, "band": "low", "as_of": "2026-09-27T09:02:11Z" }
  ]
}

Illustrative: a page could show "In stock, as of 09:02 UTC" for the first item and "Running low" for the second.

It cannot. A positive band is not a reservation, and nothing keeps stock for your customer. It shows no exact count or price on the listing routes. It cannot reach a pharmacy that is not listed or has not connected. The band unknown appears only in network search, where it means the pharmacy's till has not reported recently enough to trust. Show it as unknown, never as out of stock. A text match is not a promise that two products are the same. The events page explains the change feed, which carries no record.

Idea 2: Send a Pharmacy's Stock From Its Other Till

The idea. A pharmacy that sells through another system has that system send its stock to ClinikEHR as a report, so the pharmacy's listing can show it. It suits teams that build point-of-sale or stock software for pharmacies.

It cannot. It cannot read, adjust or receive stock. A row that matches none of the pharmacy's products is counted as unmatched and ignored, and nothing is guessed. A report is applied whole or not at all, and a rejected one answers 409 batch_rejected. A pharmacy that has not switched the mode on answers 409 external_stock_mode_required. Listings stay current only if you send regularly, because an old report makes products read as unknown. The batch_id doubles as the idempotency key. Idempotency means that sending the same write twice has the effect of sending it once.

Idea 3: Map Your Own Product Codes to a Pharmacy's Items

The idea. Register your own product codes, such as an internal stock-keeping code, against pharmacy items. Your other software can then ask whether a medicine is in stock using your own code. It suits a distributor, a purchasing tool or a health-tech team. The HMO portal version is a section of the pharmacy portal guide.

It cannot. It cannot link on a name alone. A name-only match waits as needs_review until a person confirms it. A code links on an exact match with a barcode, a NAFDAC number (from Nigeria's drug regulator) or another standard drug code. It is not a formulary, which is a list of covered medicines, and it is not a cover check. An unconfirmed code answers matched: false, which means we do not know the code, not that the medicine is out of stock. Illustrative, from the documentation's sample: one row is linked on an exact barcode, and another is needs_review because it matched by name only.

Idea 4: Watch Expiry and Reorder Levels Across Branches

The idea. Read exact stock by location and lot, and list what expires soon. Record receipts, transfers and write-offs through the pharmacy's own ledger, the stock record its staff use. A write-off takes stock off the books with a reason. It suits a team building stock-control or multi-branch software.

It cannot. It cannot move a controlled drug. An API key has no witness to countersign, so the call answers 403 controlled_drug_not_api_movable, and the clinic records that loss itself. It cannot transfer expired stock (409 expired_stock_not_transferable), archive an item that still has stock (409 item_has_stock) or delete one that has history (409 item_has_history). Receiving without an expiry date is refused (400 expiry_required). There is no purchase-order route, so it cannot place an order. A low band is the pharmacy's own reorder threshold, not a forecast. Receive, adjust, transfer and write-off each need an Idempotency-Key.

Ideas That Use Patient Data (Levels 4 and 5)

Patient information needs more yeses, set out in the level 4 and 5 rows and the order of yeses above. In both cases the clinic chooses what to grant.

Writes where a duplicate would hurt need an Idempotency-Key and are refused without one.

Idea 5: A Booking Page or Call-Centre Tool

The idea. Show a clinic's bookable services, clinicians and free times, and book a patient who already exists there. It suits a booking page, a call-centre screen or a messaging bot.

It cannot. A free time is only a hint, and nothing keeps it for you. Expect 409 slot_taken, no_provider_available or out_of_office. The API does not support group appointments, a visit that bundles several services, package redemption, a deposit or discount, or default documents. It cannot cancel a completed or no_show appointment, delete anything, or change a patient's notification consent. Duplicate patients are flagged for staff, not refused.

Idea 6: Send What a Patient Reports Before a Visit

The idea. A form collects the allergies, conditions and medicines a patient reports and sends them to the clinic for a clinician to review. It can also open a draft visit for the clinician to complete. It suits intake and pre-visit tools.

It cannot. It cannot put anything on the chart by itself: a clinician's review does that, or the clinic's own choice of automatic acceptance. It cannot change or withdraw an item the clinic accepted automatically (409 submission_not_pending). Prescriptions are read-only for every key. It cannot open a visit with clinical text or billing, or sign, lock or finalise anything. An unrecognised medicine or diagnosis code is refused (400 invalid_request). A large bulk load pauses automatic acceptance. Illustrative: a form sends one allergy and the answer is 202. Where the clinic has not chosen automatic acceptance, the item reads pending and the chart is unchanged until a clinician accepts it.

Idea 7: Send a Referral and Follow What the Clinic Does

The idea. A referring practice's software sends a referral to a connected clinic for review, then reads the status the clinic gives it. It suits a referral tool or a care-coordination product.

It cannot. It cannot accept, decline, book, complete or cancel a referral. Those are the clinic's decisions. It cannot send an outgoing referral, because the direction is always incoming today. A change or take-back works only while the referral is still received. It cannot see another party's submissions, or the clinic's reason for declining unless your key sent the referral. An empty list means none has been confirmed, not that the patient has no referrals.

An Idea for an Insurer or HMO (Level 6)

An enrollee is a member an HMO covers. A pre-authorization request asks the insurer to agree in advance to pay for care, and the answer carries a PA code. A payment advice tells the clinic what was paid, how and against which claims.

Idea 8: An Insurer's Own Console

The idea. An insurer or HMO builds its own console on the routes that read its enrollees, plans, claims and pre-authorization requests at a clinic. The console can vet claims, which means checking them line by line and deciding them. It can decide pre-authorization requests and post payment advices. The detail is in the claims tutorial, the pre-authorization guide and the connection guide. The insurtech guide gives a founder's view.

Access in full. Two Enterprise requirements stand as a pair. Your own developer workspace is on the Enterprise contract plan, which ClinikEHR sets on request. The clinic is on its Enterprise plan. Then the order of yeses above applies, with approval for the kind Insurer claims, authorizations and enrollees. The clinic's Insurance setting must be Outside the US, and its owner or a manager links your organization to its record of your insurer. No API add-on applies to an organization's key. An insurer or HMO can apply for this kind. These are gates for the API. They are separate from HMO billing inside ClinikEHR, which works on any plan once the hospital's owner sets Insurance to Outside the US.

It cannot. It cannot read another insurer's records, or anything the clinic has not yet sent. Both answer 404. It cannot approve more than was billed, create or change an enrollee, or fetch a claim's attached files, only their name, type and size. It cannot move money. A payment advice is a message, and the clinic records the money. The API does not compare claim lines with an HMO's price list. The enrollee route reads the clinic's own record, so it is not a live eligibility check.

What You Cannot Build on the ClinikEHR API, and Why

The documentation and the route list set clear limits. Do not pitch these ideas to a clinic.

• A bill estimator that uses HMO prices. No route returns an HMO's price list, called a tariff, which the hospital keeps in the app. A tariff code is only a field on claim lines, and plans carry limits and benefits but no service prices.
• Lab-result delivery. The API has no route for laboratory orders or results.
• A claim scrubber or pre-authorization dashboard sold to other hospitals. Reading a claim or request as a developer organization is refused with hmo_not_linked. An insurer never sees a claim still being prepared. The Acceptable Use Policy also bars denying cover by machine alone.
• An enrollee kiosk. Only a linked insurer organization or the clinic's own key can read enrollees.
• Refill reminders. There is no refill reminder or scheduler to build on.
• Apps on prescription pickups or outreach events. Both are documented but marked not yet available.
• Writing a prescription, signing a note or accepting a referral. No request can do these. They stay with clinic staff.
• Reading a sale's price or total, or who served the customer. No scope exposes them.

Start in Five Steps

1. List the data. Write down every kind of data your idea reads or sends, and mark each as patient data or not. Match each to a scope on the permissions page and the page for its resource. The insurance scopes are on the HMO and insurer page.
2. Pick the lowest level. Use the ladder, and ask for the fewest scopes. A request outside your approval is refused with approval_required or kind_not_approved.
3. Build on a test key. Two client libraries are published: @clinikehr/api for TypeScript on Node.js (use 0.1.3 or later) and clinikehr for Python 3.11 or later. The SDKs and Postman page lists both.
4. Get the real yes. For one clinic, ask its owner for a key. For many clinics, apply as an organization, then ask each owner for a one-time code. For questions about plans, contact ClinikEHR.
5. Check what your key reaches. Call GET https://api.clinikehr.com/v1/me for the clinic or workspace the key belongs to. Call GET https://api.clinikehr.com/v1/connections for the clinics that approved a connection, the scopes each granted and when it expires. Neither needs a scope.

How You Know It Worked

• Every item on your data list has a named scope beside it.
• A test-key read answers with invented data.
• A write repeated with the same Idempotency-Key returns the first answer.
• The connections list shows the clinic and the scopes it granted. If a scope is missing, the clinic granted less than you asked for.
• With an organization's key, a patient you are not linked to answers 404.

Mistakes That Cost Health-Tech Teams Time

1. Hunting for clinics. The Acceptable Use Policy bars using searches, errors or timings to work out which clinics exist. An organization reaches a clinic only through the code its owner gives you.
2. Using one key for many clients. The policy bars sharing a key, or using one key for several organizations.
3. Putting a key in a web page, a kiosk or a phone app. Keep it on your own backend, and never send it in a web address.
4. Making a new idempotency key on every retry. Make one when the action is first tried, and reuse it.
5. Testing automatic acceptance on a real patient. You cannot see whether a clinic has turned it on. Do not send a test item for a real patient to find out. Read review_status in the answer to every send.
6. Showing an old band as if it were current. A band is true as of its as_of time. Show that time, and read again rather than keeping an old band.

Frequently Asked Questions

What can I build with the ClinikEHR API in Nigeria?

Eight ideas map to documented scopes. Without patient data, you can build a stock badge, a stock report sent from another till, a medicine-code mapper and an expiry watch. With patient data, you can build a booking tool, a pre-visit form and a referral sender. An insurer or HMO can build its own console for claims, pre-authorization requests and enrollees. Each needs a key and the clinic's yes.

Can I read any hospital's records through the API?

No. A key on its own reaches nothing. Each request is checked against your key's permissions, what the clinic granted, what the clinic's plan includes and your plan. There is no directory of clinics. An organization reaches a clinic only through a one-time connection code its owner hands over, while a clinic's own key reaches only that clinic. The clinic can narrow or end the connection at any time, and a revoked connection is refused from your next request.

How is the ClinikEHR API different from ClinikAPI?

The ClinikEHR API at api.clinikehr.com is the API of the ClinikEHR app and works through a connected clinic's account. ClinikAPI at clinikapi.com is a separate product built around the FHIR health data standard, with its own site, keys and licence. Do not mix their keys or their documentation.

What approval do I need to use patient data?

It depends on the key. A clinic's own key needs the API add-on or an Enterprise contract, and the owner's acceptance of the API data agreement. An organization needs a contract that includes patient data, a ClinikEHR reviewer's approval for each kind of data, the accepted data-protection addendum and the clinic's approval of each scope. The clinic must be on its Enterprise plan to grant patient data. The documentation states no timeline.

Can I test with a test key?

Yes, for most of the API. A test key reaches a sandbox of invented data and never a real clinic. The insurance routes are the exception. The sandbox clinic has no insurance data, so lists answer an empty page and reads and writes answer 404. Try insurance ideas with a live key against a clinic that linked your organization. The documentation describes no sandbox for the stock-report route.

Can an outside developer build a claim scrubber or an enrollee kiosk?

No. A developer organization with no insurer link can only submit claims and pre-authorization requests, and reading any claim, request or enrollee is refused. The enrollee route is for an insurer organization the clinic linked. It reads the clinic's own record and is not a live eligibility check. A key must stay on a backend, so a kiosk screen cannot carry one.

Does the data-protection addendum make my product comply with the NDPA?

No. The addendum between Bettar Platforms, Inc. and your organization has Nigeria Data Protection Act terms, including that you are a data controller for what you receive. It is a contract, not a certificate, and it does not confirm that you meet the Act. Read the Act and ask your own lawyer. This is general information, not legal advice.

What does it cost to start?

A test key is free and reaches a sandbox. A paid workspace plan is set by ClinikEHR on request, because there is no self-serve checkout, and this guide prints no price. The developer portal has the plan page. A clinic's own key needs a clinic plan with API access, and the clinic's plans are on the pricing page.

Conclusion

Every idea here starts with one question: who has to say yes? The answer is a clinic, sometimes a ClinikEHR reviewer, and always in an order. Choose the lowest level that reaches your data, build on the sandbox, and ask the clinic for the real key or code last.

Open the developer portal to create a test key. For questions about plans or access, contact ClinikEHR. The API documentation page introduces the API.

Related Articles

• How to Build an HMO Claims Integration in Nigeria With the ClinikEHR API (Step-by-Step, 2027)
• Pre-Authorization API for Nigerian HMOs: Approve or Deny PA Requests With a PA Code (2027)
• Connecting Your HMO to the ClinikEHR API in Nigeria: Access, Approval and Data Protection Explained (2027)
• Building a Health-Insurance Startup for Emerging Markets: What Your Hospital Integration Must Do (2027 Developer Guide)
• How to Connect an HMO Portal to a Licensed Pharmacy in Nigeria: Stock Availability and Drug Request API (Developer Guide, 2027)
• ClinikEHR API documentation
• ClinikEHR API reference at docs.clinikehr.com
• ClinikEHR pricing

Facts are as of the dates shown. Check the linked sources for updates. This is general information, not legal or professional advice.