MyInvois API Integration Guide 2026: Connect Your System to LHDN

Complete technical guide to integrating with the MyInvois API in 2026. Covers the official SDK, authentication, key endpoints, UBL 2.1 document format, sandbox testing, error handling, and available SDKs and tools.

Last updated: March 202612 min readLHDN Official Portal

MyInvois API

MyInvois API Overview

The MyInvois API is the programmatic gateway to LHDN's national e-invoicing platform. It allows businesses to submit, validate, cancel, and retrieve electronic invoices without manual intervention through the MyInvois portal. Whether you are a developer building a custom integration, a CTO evaluating architecture options, or an IT manager selecting a vendor, understanding the API is essential to achieving reliable, scalable compliance.

LHDN provides the official Software Development Kit (SDK) and API documentation at sdk.myinvois.hasil.gov.my. The SDK site contains endpoint references, data dictionaries, sample payloads, authentication guides, and change logs. It should be your first stop before writing any integration code.

With Phase 4 having expanded the mandate's scope in January 2026 and a relaxation period running until December 2026, businesses of every size now need a clear integration strategy. Full enforcement begins in January 2027, which means the window to build, test, and stabilise your integration is closing. Use our cost calculator at /calculator to estimate the financial impact of different approaches, and browse certified vendors at /vendors to find a solution that fits your stack.

Integration Methods

Integration Methods Compared

There are three mainstream approaches to connecting with the MyInvois platform. Each suits a different organisational profile. The comparison below can help you choose. For a deeper analysis, see our dedicated comparison at /compare/myinvois-api-vs-middleware.

| Criterion | Direct API | Middleware / ERP Connector | Peppol Access Point | |---|---|---|---| | Development Time | 4 – 12 weeks | 1 – 4 weeks | 2 – 6 weeks | | Maintenance | In-house team required | Vendor-managed | Vendor-managed | | Cost | Higher upfront, lower recurring | Moderate subscription | Moderate to high | | Flexibility | Full control | Limited to connector scope | Network-level routing | | Technical Skill | High (developers needed) | Low to moderate | Moderate | | Best For | Large enterprises, ISVs | SMEs, mid-market firms | Cross-border traders, B2G |

Direct API integration gives you complete control over the data flow and is ideal when you have bespoke invoicing logic or need to support very high volumes. Middleware connectors, offered by many vendors listed at /vendors, let you keep your existing accounting or ERP system and simply plug in a compliance layer. Peppol Access Points add an international dimension: they route documents through the Peppol network and can simultaneously fulfil MyInvois obligations. Learn more about Peppol in our guide at /guides/peppol-malaysia.

API Architecture

API Architecture and Authentication

The MyInvois API is a RESTful service that communicates over HTTPS. It accepts and returns data primarily in JSON format, though XML is also supported for organisations that prefer it. The API follows standard REST conventions: resources are addressed by URL, actions map to HTTP verbs (POST for submission, GET for retrieval, PUT for updates), and responses use standard HTTP status codes.

Authentication relies on OAuth 2.0 client credentials. You register your application on the MyInvois developer portal to obtain a client ID and client secret. These credentials are exchanged for a bearer access token, which you include in the Authorization header of every subsequent request.

Access tokens are valid for 60 minutes by default. Best practice is to cache the token locally and refresh it proactively before expiry rather than waiting for a 401 response. This avoids unnecessary latency in time-sensitive submission flows.

For complex or high-volume operations, the API uses asynchronous processing. You submit a batch of documents and receive a submission reference immediately. The platform then validates each document in the background. You poll dedicated result-polling APIs to check status, retrieving outcomes such as "Valid", "Invalid", "In Progress", or "Cancelled".

LHDN provides a sandbox environment that mirrors production. Sandbox credentials are separate, and the base URL differs, but the API surface is identical. Always develop and test against the sandbox before pointing your application at production.

Key API

Key API Endpoints

The MyInvois API surface is divided into two groups: e-Invoice APIs for document lifecycle management and Platform APIs for reference data.

e-Invoice APIs:

- Submit Signed Documents: POST endpoint that accepts one or more digitally signed e-invoice documents in UBL 2.1 JSON or XML. The system returns a submission ID for tracking. - Cancel Documents: Allows the supplier to cancel a previously validated document within the 72-hour window. Requires the document UUID and a cancellation reason. - Reject Invoices: Enables the buyer to reject an invoice they believe is incorrect, also within 72 hours of issuance. - Search Sent Documents: Query your own submitted documents by date range, status, buyer TIN, or document type. - Search Received Documents: Query documents sent to you by suppliers, with similar filter options. - Get Document Details: Retrieve the full validated document including QR code URL and LHDN metadata. - Get Document Status: Lightweight call to check the current status of a single document by UUID.

Platform APIs:

- Retrieve Document Types: Returns the list of supported document types (invoice, credit note, debit note, refund note, self-billed invoice, and others). - Get Document Type Details: Returns the full schema and field requirements for a specific document type, including mandatory fields, allowed values, and validation rules.

All endpoints require a valid bearer token. Responses follow a consistent envelope structure with a status field, optional error array, and a data payload.

Document Format

Document Format and Validation

MyInvois documents conform to the UBL 2.1 (Universal Business Language) standard with Malaysia-specific extensions. UBL 2.1 is an internationally recognised specification maintained by OASIS, making Malaysian e-invoices structurally compatible with global trade document standards.

Mandatory fields for a standard invoice include: supplier TIN, supplier name, supplier SST registration number (where applicable), buyer TIN (for B2B), invoice number, issue date, currency code, line items with descriptions, quantities, unit prices, classification codes (based on the Malaysian Standard Industrial Classification), tax subtotals by category, and total payable amount.

TIN validation is performed in real time against LHDN's taxpayer database. An invalid or inactive TIN will cause immediate rejection. Ensure your system validates TINs locally before submission to reduce unnecessary API calls and speed up processing.

Classification codes deserve special attention. Each line item must carry a valid MSIC code that categorises the goods or services. Incorrect classification is one of the most common rejection reasons. The full code list is available in the SDK documentation at sdk.myinvois.hasil.gov.my.

Both JSON and XML payloads must be digitally signed before submission. The signing process uses the certificate issued during your MyInvois onboarding. The SDK documentation provides step-by-step signing instructions and sample code.

Testing in

Testing in the Sandbox Environment

LHDN provides a dedicated sandbox (pre-production) environment at a separate base URL. The sandbox mirrors the production API surface, allowing you to test every endpoint without creating real tax records.

Getting started:

1. Register for sandbox access on the MyInvois developer portal at sdk.myinvois.hasil.gov.my. 2. Obtain sandbox-specific client credentials (client ID and secret). These are entirely separate from production credentials. 3. Configure your application to use the sandbox base URL. 4. Use test TINs provided by LHDN for both supplier and buyer fields. Production TINs will not validate in the sandbox.

Recommended test scenarios:

- Submit a valid standard invoice and confirm a successful validation response. - Submit invoices with deliberate errors (missing mandatory fields, invalid TIN, wrong classification code) and verify your error-handling logic parses the rejection correctly. - Test batch submission with varying batch sizes to understand throughput and asynchronous polling behaviour. - Cancel a validated document within 72 hours and confirm the status change. - Reject a received invoice as the buyer. - Refresh an expired access token mid-flow and confirm seamless retry. - Simulate rate-limiting scenarios to validate your backoff logic.

The sandbox may lag slightly behind production when LHDN releases updates. Monitor the SDK portal's change log for sandbox release notes. Once all test scenarios pass, switching to production is simply a matter of updating the base URL and credentials.

Error Handling

Error Handling and Common Issues

A production-grade integration must handle errors gracefully. The MyInvois API returns structured error responses with codes, messages, and field-level details.

HTTP status code categories:

- 200 OK: Request succeeded. - 400 Bad Request: Validation failure. The response body contains an array of error objects specifying which fields failed and why. - 401 Unauthorised: Access token is missing, expired, or invalid. Refresh the token and retry once. - 404 Not Found: The requested document UUID does not exist. - 429 Too Many Requests: Rate limit exceeded. Honour the Retry-After header. - 500 / 502 / 503: Server-side issue. Retry with exponential backoff.

Recommended retry logic:

- Transient errors (429, 5xx): Retry up to three times with exponential backoff — for example, wait 1 second, then 4 seconds, then 16 seconds. - Validation errors (400): Do not retry. Log the full error payload, flag the document for review, and alert the responsible team. - Authentication errors (401): Refresh the token and retry the original request once. If it fails again, halt and investigate.

Common rejection reasons in production:

- Invalid or inactive TIN for supplier or buyer. - Missing mandatory fields such as classification code or currency. - Tax calculation mismatch (line-level totals do not sum to the document total). - Duplicate invoice number for the same supplier and date. - Digital signature validation failure.

Investing in comprehensive logging — capturing request payloads, response bodies, and timestamps — will dramatically reduce your mean time to resolution when issues arise.

Step-by-Step Integration

Step-by-Step Integration Guide

Follow these steps to move from zero to a production-ready MyInvois API integration:

1. Register on the MyInvois developer portal: Visit sdk.myinvois.hasil.gov.my and create an account. Complete your organisation's taxpayer profile and request API credentials.

2. Obtain sandbox credentials: Generate a client ID and client secret for the sandbox environment. Keep these secure — store them in environment variables or a secrets manager, never in source code.

3. Study the SDK documentation: Review the endpoint references, data dictionaries, and sample payloads. Pay close attention to mandatory fields and signing requirements.

4. Build the authentication layer: Implement the OAuth 2.0 client credentials flow. Cache the access token for up to 60 minutes and refresh proactively.

5. Implement document generation: Map your internal invoice data model to the UBL 2.1 JSON or XML structure. Include all mandatory fields, validate TINs locally, and apply the correct classification codes.

6. Implement digital signing: Sign each document using the certificate provided during onboarding. The SDK includes signing examples.

7. Build submission and polling logic: Submit documents via the API, store the submission reference, and poll the result endpoint until validation completes.

8. Implement error handling: Parse error responses, categorise them, and route each category to the appropriate recovery path (automatic retry, manual review, or alert).

9. Test thoroughly in the sandbox: Run every scenario listed in the testing section above. Involve your finance team in validating that output documents match business expectations.

10. Go live: Update your base URL and credentials to production. Monitor closely for the first few weeks, reviewing logs daily and addressing any rejections promptly.

If building in-house is not feasible, explore pre-built solutions from certified vendors at /vendors.

Available SDKs

Available SDKs and Tools

Beyond the official SDK documentation at sdk.myinvois.hasil.gov.my, the developer community and third-party vendors have produced several resources to accelerate integration.

Official resources:

- MyInvois SDK Portal: The authoritative source for endpoint documentation, schema definitions, sample payloads, and change logs.

Third-party SDKs and packages:

- PHP SDK: A community-maintained PHP library that wraps the MyInvois API, handling authentication, document construction, signing, and submission. - Laravel Package: A dedicated Laravel package for MyInvois, providing service providers, facades, and Artisan commands for common operations. Ideal for teams already using the Laravel framework. - Postman Collection: A pre-built Postman collection containing every MyInvois endpoint with sample request bodies. Useful for manual testing, debugging, and onboarding new team members.

Choosing the right tool depends on your technology stack, team size, and maintenance appetite. Official SDKs offer the most reliable long-term support. Community packages save time but may lag behind API changes — always verify compatibility with the latest SDK version.

For businesses that prefer a fully managed approach, many vendors at /vendors offer turnkey solutions that abstract away the API entirely, handling document generation, signing, submission, and error recovery behind a simple user interface or accounting-system plugin.

Regardless of which tools you choose, allocate time for monitoring and maintenance. LHDN periodically updates the API, and staying current with the SDK change log ensures your integration remains compliant and functional.

FAQ

Frequently Asked Questions

Register on the MyInvois developer portal at sdk.myinvois.hasil.gov.my, obtain OAuth 2.0 client credentials (client ID and secret), and exchange them for a bearer access token. Include that token in the Authorization header of every API request. Start with the sandbox environment before moving to production.
The MyInvois SDK is the official developer resource provided by LHDN at sdk.myinvois.hasil.gov.my. It includes endpoint documentation, data dictionaries, UBL 2.1 schema definitions, sample payloads, digital-signing guides, and change logs. It is the authoritative reference for any API integration.
Not necessarily. You can integrate directly via the API, use a pre-built middleware or ERP connector from a certified vendor, or connect through a Peppol Access Point. Many vendors listed at /vendors offer turnkey solutions that handle API communication on your behalf, requiring no custom development.
The MyInvois API is language-agnostic — any language that can make HTTPS requests and handle JSON or XML can integrate. Community resources include a PHP SDK and a Laravel package. Postman collections are also available for testing without writing code.
A direct API integration typically takes 4 to 12 weeks depending on complexity, team experience, and the number of document types you need to support. Middleware connectors can reduce this to 1 to 4 weeks. Allow additional time for sandbox testing, user acceptance testing, and staff training.
Yes. LHDN provides a sandbox environment that mirrors production. You receive separate sandbox credentials and use test TINs supplied by LHDN. The sandbox lets you validate your submission, cancellation, rejection, and error-handling flows without affecting real tax records.
Direct API integration means your system communicates with MyInvois endpoints directly, giving you full control but requiring in-house development and maintenance. Middleware integration uses a third-party layer that sits between your system and the API, handling format conversion, signing, submission, and error recovery. Middleware is faster to deploy and requires less technical skill. See /compare/myinvois-api-vs-middleware for a detailed comparison.

Ready to Find Your E-Invoicing Solution?

Use our readiness calculator to get matched with LHDN-compliant vendors tailored to your industry and business size.

EInvoicingMalaysia.com is an independent directory. We are not affiliated with LHDN or the Malaysian government.