# Slade360° Advantage API Documentation > REST APIs for Slade360° Advantage, the platform a hospital system connects to in order to identify a patient, verify what their cover pays for, take consent, bill a visit and get reimbursed — and, on a separate branch, to raise KRA-compliant tax invoices through eTIMS. The documented surface is 189 operations across 165 paths in five services: the Rail, Terminology, Authentication, Slade360 eTIMS, and Slade Advantage. The Rail is the integration path most readers want and is published as a draft contract, versioned 0.1.0-draft; the other four are shipped surfaces. Read the rail in order. It is ten stops from Authenticate to Reconcile, and each one assumes the identifiers the stop before it returned, so the sequence is the contract rather than a suggestion. An integrator who starts at Bill will be missing the patient, the cover and the consent that stop needs. Two things are true of every v2 call on the rail and are the most common cause of a call that fails in a way that does not look like a header problem. Every request carries a bearer token from the Authentication service, and every request carries the facility context as the pair X-Facility-Id and X-Facility-Id-Type. A call made without the pair is judged against the wrong facility, and the failure surfaces stops later as a patient or payer problem. Each page below is linked as markdown. Drop the .md suffix for the rendered HTML page, which carries the same content at many times the size. The specs under /specs/ are the machine-readable truth for any endpoint; where a page and a spec disagree, the spec is right. ## Start here Read these three before anything else. Onboarding comes first because no stop on the rail is callable until a provider account exists and has been activated, which is a funnel a human walks and not an API call you can make. - [Slade360° Advantage for integrators](/introduction.md): What Advantage is, the two integration paths it offers, the credentials and headers every call needs, and where the machine-readable specs live. Start at the top. - [Onboarding onto Advantage](/rail/concepts/Onboarding.md): How a provider gets an account before the rail begins: a registry lookup, a code sent to the address the registry already holds, then activation. The individual track, the business track, and the branches off both. - [The rail, end to end](/rail/concepts/The-Eight-Steps.md): What the rail is, what a visit on it looks like from arrival to payment, and how to tell when your integration is done. - [Skills for coding agents](/skills.md): If you are a coding agent, install these first. Two skills carrying the rail's operations and error codes and the eTIMS code tables, generated from the same registries this site reads, served at /.well-known/skills/index.json. ## The rail, in order Ten stops, Authenticate through Reconcile. Read them in this order. Each one names the identifiers it needs from the stop before, so the numbering is a dependency chain rather than a table of contents. Every v2 call here carries a bearer token and the X-Facility-Id / X-Facility-Id-Type pair. - [00 · Authenticate](/rail/stops/Authenticate.md): Getting your system onto the rail. You need credentials, a cached token, and the facility context that every later call is judged against. - [01 · Identify](/rail/stops/Identify.md): Resolve whoever is standing at the front desk to a unique_patient_id, the value every later step keys off, and read back masked details so you can confirm you have the right human. - [Dependants and the hard cases](/rail/guides/Beneficiary-Lookup.md): The lookups that are not a national ID typed by a conscious adult. Dependants reached through a principal, the situations a busy front desk runs into, and what to do when the registry is slow. - [Resolving the clinician](/rail/guides/Clinician-Identity.md): The clinician's identity is a registration number plus the body that issued it. Read the licence verdict live, and take the four things the health worker registry buys you. - [02 · Verify cover](/rail/stops/Entitle.md): Checking eligibility per cover, selecting one, then walking down to a billable procedure. What you end up with is a filtered set of items with numbers attached. - [What a cover pays for](/rail/guides/Benefit-Tree.md): How the benefit tree is shaped, why the same rule lives at different depths for different payers, and how to walk it one level at a time. - [03 · Consent](/rail/stops/Consent.md): One call for every mode of consent. Send the member, facility and purpose; the rail runs the right factor and hands back a proof you spend later. - [04 · Visit](/rail/stops/Visit.md): Open the encounter locally, spend the consent the ceremony minted, and grow the visit into authorized lines — finding out what a payer blocks at the desk, not in a rejected claim a week later. - [05 · Treat](/rail/stops/Treat.md): Record what was found and what was done. The diagnosis is coded, linked to the intervention it justifies, and contributed to the record that follows the patient. - [Orders, results and prescriptions](/rail/guides/Orders-And-Prescriptions.md): How to order a test from a facility that is not yours, get the result back without building a second integration, and write a prescription the patient can fill at any pharmacy on the rail. - [Referrals, samples and one authentication](/rail/guides/Referrals.md): Send a patient or a specimen onward with the record attached, and let the authorisation taken at the source facility stand at the destination, so nobody travels twice. - [Going paperless on day one](/rail/guides/Paperless.md): Record the clinical facts once and the rail generates the documents a claim requires, as HTML to show on screen or as a PDF to sign and attach. Your HMIS never authors a document. - [06 · Preauthorize](/rail/stops/Preauth.md): Get approval before the work is done. One envelope, one clinical block chosen by the benefit type, and a decision that can cover only part of what you asked for. - [07 · Bill](/rail/stops/Bill.md): Add what was actually done. Each line is priced and reserved when you add it, and checked against combination rules at that moment rather than at submission. - [08 · Submit](/rail/stops/Submit.md): Closing the visit needs its own consent, then six gates decide whether the claim can go. Pre-flight holds no surprises because the same checks were running while you billed. - [09 · Reconcile](/rail/stops/Reconcile.md): Approved is not paid. Match each remittance to the invoice it settles, account for every gap, and find out why the money has not arrived. ## Why the rail works this way Background rather than instructions. Read The problem first if you are deciding whether to integrate at all; read next_action before you write the client, because it decides whether the sequence lives in your code or comes back in the responses. - [The problem, in one page](/rail/why/The-Problem.md): What it costs to connect a health system to Kenya's payers without a rail, and why the cost is not where teams expect it. - [What the rail absorbs](/rail/why/What-The-Rail-Absorbs.md): One surface, one contract. What stays yours, what stops being yours, and where the payer differences went. - [Benefit coordination](/rail/why/Benefit-Coordination.md): What happens when one patient holds several covers at once: who pays first, what tops up, and what the rail works out for you. - [The next_action contract](/rail/concepts/Next-Action.md): Every response tells you what to call next. A client that switches on this one enum can drive the whole flow without payer-specific logic. - [The integrator's view](/rail/concepts/Integrator-View.md): What the person at the desk sees, what your system calls behind them, and the screens you will end up needing whether or not you planned for them. ## eTIMS branch Raising KRA-compliant tax invoices, plus the Slade Advantage collect surface. Independent of the rail: these calls need credentials and a business activated for eTIMS, not a patient or a cover. Self-onboarding comes first, because the API answers nothing until the business is activated. - [Getting Started](/docs/eTIMS/Getting-Started.md): What the Slade360 eTIMS API covers and the order to work through it when you start integrating. - [Self Onboard on eTIMS](/docs/eTIMS/How-To-Guides/Self-Onboard-on-eTIMS.md): Create your Slade360 Advantage account and activate your business for eTIMS, step by step. - [Start Using the Slade360 eTIMS API](/docs/eTIMS/How-To-Guides/Start-Using-the-eTIMS-API.md): What to do from getting credentials through to your first live invoice, including how VSCU deployment is handled. - [Create an eTIMS Invoice](/docs/eTIMS/How-To-Guides/Create-an-eTIMS-Invoice.md): Create a tax invoice, process it, and sign it with the Slade360 eTIMS API, from draft through to KRA verification. - [Querying List Endpoints](/docs/eTIMS/How-To-Guides/Querying-List-Endpoints.md): How to narrow an eTIMS list response using field selection (sparse fieldsets), filters, search, and pagination. - [ERPNext plugin: Kenya Compliance via Slade 360](/docs/eTIMS/Plugins/ERPNext/Getting-Started.md): Integrating from ERPNext: install the Kenya Compliance via Slade 360 app rather than calling the API directly. Not linked from the sidebar, and the only documentation of this path. - [CargoWise Invoice Intake](/docs/eTIMS/Plugins/CargoWise/Invoice-Intake.md): Integrating from CargoWise: submitting XUT and XUD invoice documents into the eTIMS pipeline. Not linked from the sidebar, and the only documentation of this path. - [Getting Started](/docs/Slade-Advantage/Getting-Started.md): What the Slade Advantage API is for and where its endpoints are documented. - [M-Pesa Paybill / Till Setup](/docs/Slade-Advantage/How-To-Guides/Mpesa-Paybill-Till-Setup.md): How to apply for a Safaricom Paybill or Till and get the Daraja API credentials Slade Advantage needs. ## Reference Opened on demand, not read through. The error dictionary and the value sets are the two an integration will reach for most. - [Error dictionary](/rail/reference/Errors.md): Every error code the rail can return, what it means, what to do about it, and how to retrieve the whole set as a value set instead of transcribing it. - [Value sets and code systems](/rail/reference/Value-Sets.md): Every coded list the rail uses, where to fetch it from the terminology service, and how to keep a local copy from drifting. - [Not yet settled](/rail/reference/Time-Limits.md): Read before hard-coding any time bar, enforcement flag or deadline. The training material, the conformance specification and the system defaults currently disagree, so this page sets the figures out as an unresolved conflict rather than as guidance. Nothing on it is safe to hard-code; keep these values in configuration. - [The whole surface](/rail/reference/Terminology-Service.md): The consumer-facing surface of the national terminology service, group by group: discovery, concepts, FHIR operations, value sets, versioned reads, benefits, rates, search and export. - [Walking a concept tree](/rail/reference/Terminology-Walking-The-Tree.md): Large vocabularies are hierarchies, and the list you are handed often starts partway down one. How to render a tree lazily, climb from a leaf to its parents, and avoid rebuilding the hierarchy yourself. - [Validating a code](/rail/reference/Terminology-Validating-Codes.md): Check a code at the boundary where it enters your system, not at submission. What $validate-code answers, why it returns 200 for an invalid code, and where a translation belongs. - [Pinning to a release](/rail/reference/Terminology-Pinning-Versions.md): A vocabulary changes without your release cycle noticing. What version=serving resolves to, how an owner pins a release, and the reads that tell you what changed, so a terminology update is not an incident. - [Translating between vocabularies](/rail/reference/Terminology-Concept-Maps.md): Code a diagnosis once and let the crosswalk work out the rest. How to find the right concept map, how to read $translate, what an equivalence promises, and the difference between "no mapping" and "not mapped yet". - [Getting the data you need](/rail/reference/Terminology-Getting-Data.md): Every way a coded list leaves the terminology service: paged JSON, FHIR, CSV, Excel, or a bare list of codes. Choose the shape by who is reading it. - [Taxpayer Status](/docs/eTIMS/References/Customers/Taxpayer-Status.md): KRA eTIMS taxpayer status codes (taxprSttsCd). - [Import Item Status](/docs/eTIMS/References/Imports/Import-Item-Status.md): KRA eTIMS import item status codes (imptItemSttsCd). - [List KRA Item Classification](/docs/eTIMS/References/Item/Item-Classification.md): KRA Item Classification is how the Kenya Revenue Authority (KRA) groups items by their tax treatment. - [Item Code Structure](/docs/eTIMS/References/Item/Item-Code-Structure.md): How the unique KRA eTIMS item code (itemCd) is composed. - [Packaging Units](/docs/eTIMS/References/Item/Packaging-Units.md): KRA eTIMS packaging unit codes (pkgUnitCd). - [Product Types](/docs/eTIMS/References/Item/Product-Types.md): KRA eTIMS product type codes used when registering an item. - [Quantity Units](/docs/eTIMS/References/Item/Quantity-Units.md): KRA eTIMS unit of quantity codes (qtyUnitCd). - [Purchase Receipt Types](/docs/eTIMS/References/Purchases/Purchase-Receipt-Types.md): KRA eTIMS purchase receipt type codes. - [Registration Types](/docs/eTIMS/References/Purchases/Registration-Types.md): KRA eTIMS registration type codes (regTyCd). - [Credit Note Reasons](/docs/eTIMS/References/Sales/Credit-Note-Reasons.md): KRA eTIMS credit note reason codes (rfdRsnCd). - [Credit Note Rules](/docs/eTIMS/References/Sales/Credit-Note-Rules.md): KRA eTIMS validation rules for credit notes, and the difference between full and partial credit notes. - [Payment Methods](/docs/eTIMS/References/Sales/Payment-Methods.md): KRA eTIMS payment method codes (pmtTyCd). - [Sales Receipt Types](/docs/eTIMS/References/Sales/Sales-Receipt-Types.md): KRA eTIMS sales receipt type codes (rcptTyCd). - [Transaction Progress](/docs/eTIMS/References/Sales/Transaction-Progress.md): KRA eTIMS transaction progress / status codes (salesSttsCd, pchsSttsCd). - [Transaction Types](/docs/eTIMS/References/Sales/Transaction-Types.md): KRA eTIMS transaction type codes for sales and purchases. - [Stock Movement Types](/docs/eTIMS/References/Stock/Stock-Movement-Types.md): KRA eTIMS stock in and stock out movement type codes (sarTyCd). - [Tax Types](/docs/eTIMS/References/Taxes/Tax-Types.md): KRA eTIMS tax type codes A to E and their VAT rates. ## API specifications Prefer these over the prose for anything about a field, an enum or a status code. Where a page and a spec disagree, the spec is right. The .json files are the bundled OpenAPI documents the rendered references are built from, so they carry the same content without the HTML. - [The Rail — OpenAPI](/specs/rail.json): 44 operations across 40 paths, tagged by stop and in stop order. Version 0.1.0-draft: this is a contract under review, and some operations are documented as designed rather than as registered. Servers: api-dev.slade360edi.com/orchestrator and api.slade360edi.com/orchestrator. - [Authentication — OpenAPI](/specs/auth.json): One operation, the token exchange. Every other call on this site depends on it. Servers: identity-dev.slade360edi.com and identity.slade360edi.com. - [Slade360 eTIMS — OpenAPI](/specs/etims.json): 34 operations across 33 paths, version 2.3. The tax-invoicing surface. Servers: api-dev.slade360edi.com/erp and api.erp.slade360.co.ke. - [Terminology Service — OpenAPI](/specs/terminology.json): 47 operations, version v2. Coded lists, concept trees, code validation and concept maps. Fetch value sets from here rather than hard-coding them. - [Slade Advantage — OpenAPI](/specs/advantage.json): 63 operations across 44 paths, version 1.0.0. The collect and ERP surface. - [Rail operation registry](/agent/operations.json): The rail's operations as a flat list: stop, method, path, required headers, and a `planned` flag marking operations the rail is designed around but which the service does not register yet. The one artifact that says which calls answer today. - [Agent skills index](/.well-known/skills/index.json): Two installable skills, slade360-advantage-rail and slade360-etims-invoicing, with every file each one owns. Install with `npx skills add `. Mirrored at /.well-known/agent-skills/index.json. - [Error dictionary](/terminology/rail-errors.json): Every error code the rail returns, with what it means and what to do about it. Also published as FHIR at /terminology/rail-errors.codesystem.json and /terminology/rail-errors.valueset.json. - [Postman collections](/postman/rail-full-journey.postman_collection.json): The whole rail as one runnable collection. Per-stop collections are at /postman/rail-NN-.postman_collection.json, and the sandbox environment at /postman/rail-sandbox.postman_environment.json.