eTIMS API Integration Kenya for POS, ERP & Platforms | Risiti

Connect POS, ERP, SaaS and marketplaces to KRA eTIMS through one API. Start in sandbox, add merchants, submit invoices, use webhooks and go live safely.

KRA provides OSCU and VSCU for businesses and software providers integrating an existing invoicing system with eTIMS. Risiti sits at the product-integration layer: your server calls the Risiti API, while each connected business keeps its own taxpayer identity, branch, invoice sequence and compliance history.

Use the sandbox to build and test without production access. Moving live is a separate controlled step that requires an active platform plan, a readiness review and the applicable KRA production approval and credentials. Risiti is not KRA and this page does not replace KRA's current technical specifications or certification process.

Who the Risiti eTIMS API is for

The API is designed for products that already create a sale, order, job card, booking or ledger entry and need to add compliant Kenyan tax invoicing without forcing users into a second daily system.

POS and retail systems issuing receipts for many independent businesses.
ERP and accounting products that need eTIMS submission and reconciliation.
SaaS products for garages, property managers, clinics, hospitality and field services.
Marketplaces, ecommerce systems and merchant platforms operating structured multi-business workflows.
Procurement and aggregator platforms preparing for buyer-initiated or reverse-invoicing workflows.

A practical integration flow

Create a platform workspace and a sandbox API key, register each connected business as a merchant, then submit invoices with a stable Idempotency-Key from your own system. Invoice creation is asynchronous: an accepted API request means Risiti has received the work, not that KRA has completed it.

Keep pending, retrying, submitted and failed states visible in your product. Use signed webhooks for status changes and the invoice endpoint for reconciliation. A submitted invoice can include KRA receipt data, control-unit metadata, QR data and a public receipt URL.

Sandbox base URL: https://sandbox-api.getrisiti.com/v1
Production base URL: https://api.getrisiti.com/v1
Authentication: server-side Bearer API keys; never expose a key in browser or mobile code.
Write safety: stable idempotency keys prevent accidental duplicate merchant and invoice operations.
Operations: request IDs, API logs and webhook delivery history support troubleshooting and reconciliation.

Sandbox first, production by approval

A new workspace can use sandbox before paying for live access. Sandbox keys create test merchants and exercise the API contract against the sandbox environment. They cannot be switched into production by changing a URL or request field.

Production keys remain server-gated. Live access requires the platform subscription and a review of the organization, KRA ownership, integration contact, sandbox results, webhook handling and operational readiness. Every connected merchant still needs the taxpayer and OSCU setup required for live submission.

OSCU, VSCU and the Risiti API are different layers

KRA describes OSCU as suitable for systems that are always online and VSCU as suitable for bulk invoicing or systems that are not always online. Both are official KRA system-to-system routes with development, sandbox testing, vetting and certification requirements.

Risiti's public API gives product teams a stable merchant and invoice contract. It does not rename itself as KRA's API, and using Risiti does not remove taxpayer verification or any approval KRA requires. Your architecture decision should be based on transaction timing, connectivity, volume, branch structure and reconciliation needs.

Built for failure handling, not only successful demos

eTIMS submission can be delayed by validation problems, network conditions or an upstream response. Treat a 202 response as accepted for processing and treat submitted as the clean terminal state. Validation failures need corrected data; temporary failures should be retried with backoff and the same idempotency key.

Production integrations should alert on old pending invoices, repeated failures and webhook dead letters. Support staff should be able to find a request by request ID, merchant, external invoice ID or API log without exposing credentials or raw infrastructure details to end users.

Buyer-initiated invoicing is available in sandbox preview

KRA currently documents buyer-initiated and reverse invoicing for structured supply chains where buyers purchase from small suppliers who cannot issue eTIMS invoices themselves. KRA says these workflows use dedicated system-to-system integration and require the applicable KYC, consent and technical process.

Risiti now exposes a sandbox buyer-invoice resource so procurement platforms can test creation, seller approval or rejection, consent expiry, signed webhooks and audit history alongside ordinary sales invoicing. Live KRA transmission remains disabled until the buyer's approved route and production capability are configured.

What to prepare before integration

Map the business that legally issues each invoice, the branch ID, item and tax-code ownership, original invoice identifiers, buyer PIN rules and how users will see pending or failed submissions. Decide which system owns retries and which system remains the financial source of truth.

A stable internal merchant ID and invoice ID for every API object.
A backend service that stores API keys securely and can rotate them.
An HTTPS webhook receiver with signature verification and idempotent event processing.
A reconciliation job for invoices that remain pending or miss a webhook.
An operator workflow for validation failures, credit notes and production incidents.

Frequently asked questions

Does KRA provide an eTIMS API?

Yes. KRA provides system-to-system integration through OSCU and VSCU. KRA positions OSCU for always-online systems and VSCU for bulk or not-always-online workflows. Development, sandbox testing, vetting and certification requirements apply.

What is the Risiti eTIMS API?

It is a versioned API for platforms to register connected businesses, submit invoices asynchronously, receive receipt status, operate webhooks and inspect request logs. It is a Risiti product layer and is not the KRA API itself.

Can developers test eTIMS integration in a sandbox?

Yes. A Risiti platform workspace can create sandbox keys and test merchants, invoices, statuses and webhooks before requesting live access. Sandbox keys cannot submit production invoices.

Can one integration serve multiple businesses?

Yes. Each business is represented as a separate merchant and retains its own taxpayer identity, branch, invoice sequence, production readiness and compliance history.

When is an API-created invoice complete?

POST /v1/invoices accepts work asynchronously. The invoice is complete only when its status becomes submitted and the KRA receipt fields are available. Pending and retrying are not final receipt states.

Does Risiti support buyer-initiated invoicing?

Risiti provides a sandbox preview for buyer-invoice creation, consent states, signed webhooks and audit history. Live KRA transmission is not generally available and requires the buyer's applicable KRA approval and controlled Risiti enablement.

Does using Risiti automatically certify my company with KRA?

No. Risiti does not claim that creating an account replaces KRA's taxpayer, technical, vetting or certification requirements. Production access is controlled and depends on the applicable Risiti and KRA readiness checks.