API Development in Riyadh for Open Banking, E-Invoicing, Government and Enterprise

Custom API development in Riyadh addresses Saudi Arabia's open banking evolution under SAMA, ZATCA e-invoicing mandate, government digital platform integration and enterprise modernisation aligned with Vision 2030. SAMA open banking drives API investment in the financial sector. ZATCA e-invoicing requires API integration for every Saudi taxpayer in notified waves. Nafath and Absher are government identity platforms. SADAD (bill payment) and mada (payment network) are SAMA-regulated payment infrastructure operated by Saudi Payments. All require API integration across industries. Vision 2030 drives enterprise digital transformation creating demand for modern API architectures. ZTABS builds APIs for Riyadh enterprises, remote-first by design with an office in Houston, Texas.

Our API development services cover every Riyadh requirement from SAMA open banking to ZATCA e-invoicing.

Riyadh API development at a glance

Sector	API need	Key requirement
Open banking	SAMA compliance, payment services, account info	SAMA licensing, Islamic finance
E-invoicing	ZATCA clearance, simplified reporting	Phase 2 wave compliance, XML/cryptographic
Government	Nafath, Absher, SADAD, mada	Provider authorisation, Arabic-first
Enterprise	Vision 2030 modernisation, ERP, SaaS	Legacy system integration, microservices

SAMA open banking APIs

The Saudi Central Bank (SAMA) is implementing an open banking framework for licensed banks and financial institutions.

Payment initiation APIs enable authorised providers to initiate payments from customer accounts with consent. SAMA released the second iteration of payment initiation specifications in September 2024 with the current profile. Implementation follows SAMA technical specifications for authentication, authorisation and transaction processing. SAMA licensing and regulatory authorisation are separate from API technical implementation.

Account information APIs provide authorised providers access to customer account data (balances, transactions, product details) with customer consent. Consent management implements granular scope selection, time-bound access and revocation capabilities.

Islamic finance APIs handle distinct product types including Murabaha (cost-plus financing), Ijara (leasing), Mudarabah (profit-sharing), Musharakah (partnership) and Takaful (cooperative insurance). Islamic banking products have different calculation methods, profit distribution mechanisms and reporting requirements compared to conventional banking. API data models must accurately represent these product structures.

Security and authentication implements OAuth 2.0 with strong customer authentication, mTLS for institution-to-institution communication, certificate management and comprehensive audit logging aligned with SAMA cybersecurity framework requirements.

SADAD integration connects with Saudi Arabia's bill payment system for utility, government and commercial bill payments. SADAD APIs handle payment initiation, payment status tracking, refund processing and reconciliation. Merchant and biller access is typically through a contracted bank or payment service provider with their approval, credentials and technical requirements. Direct SADAD participant roles have additional scheme-level agreements.

mada integration supports Saudi Arabia's national payment network for debit card transactions. mada APIs handle authorisation, settlement, refund and void operations with mada-specific processing requirements. Merchant acceptance is typically enabled through a contracted acquirer or payment service provider (such as those offering mada SDKs and plugins). Direct mada participant roles have additional SAMA and scheme certification requirements.

ZATCA e-invoicing APIs

ZATCA (Zakat, Tax and Customs Authority) mandates electronic invoicing for Saudi taxpayers, with Phase 2 implementation rolling out in waves based on revenue thresholds and ZATCA notification.

Standard invoice clearance (B2B and B2G) requires Phase 2 clearance before the invoice is shared with the buyer: generating UBL 2.1 XML invoices per ZATCA specifications, submitting to the ZATCA platform for clearance, and receiving the cleared invoice with ZATCA cryptographic stamp and QR code before sharing. APIs must handle clearance request submission, status polling, cleared invoice retrieval and error handling for rejected invoices.

Simplified invoice reporting (B2C) requires reporting invoices to ZATCA within 24 hours of issuance. Offline behaviour follows actual invoice type and reporting window. APIs generate invoices with cryptographic device stamps and QR codes at the point of sale, then batch-report to ZATCA within the reporting window.

Cryptographic requirements include digital signing of invoices using ZATCA-issued cryptographic stamp identifiers (CSIDs). The ZATCA directory of solutions is indicative and nonbinding, not an approval of each e-invoicing solution; actual cryptographic certificates and solution compliance are separate from directory listing. QR code generation containing invoice hash, seller tax identification number and other required fields and ZATCA platform certificate management.

ERP integration connects ZATCA e-invoicing APIs with SAP, Oracle, Microsoft Dynamics and other ERP systems. Integration handles invoice data extraction from ERP, format conversion to ZATCA UBL 2.1 XML, submission and status synchronisation back to ERP records.

Wave-specific implementation. ZATCA notifies taxpayers of their Phase 2 compliance date. The specific requirements (standard clearance versus simplified reporting) depend on the taxpayer's invoice types and the wave notification. Early implementation before notification allows testing and operational readiness.

Government API integration

Riyadh's government digital platforms require API integration across industries for identity verification, workforce management and public services.

Nafath integration provides digital identity verification for Saudi applications, replacing manual identity verification processes. Integration requires registration and approval through the National Information Center (NIC). Not all applications can directly access Nafath; provider authorisation determines access scope and authentication levels. API development prepares integration architecture, but production access depends on NIC approval processes.

Absher integration handles government services including passport, visa, traffic and civil status operations. Absher APIs enable applications to verify identity documents, check service status and submit service requests where authorised.

Government service APIs connect with various Saudi government platforms for business registration, commercial licensing, workforce management (Qiwa platform) and social insurance (GOSI). Each platform has specific registration, approval and technical requirements. Direct access requires authorisation from the respective authority.

Arabic-first API design

Unicode normalisation handles Arabic text with proper Tashkeel (diacritical marks) management, Hamza variations (on Alef, standalone, on Waw, on Yaa) and consistent text representation across input validation, storage and search operations.

RTL content handling ensures proper bidirectional text in API responses, particularly for mixed Arabic-English content, numbers within Arabic text and formatted output like addresses and invoice data.

Arabic search and sorting implements Arabic-aware collation for database queries, search indexing and result sorting. Arabic text search must handle morphological variations, root-based search patterns and diacritical mark sensitivity options.

Bilingual API architecture serves Arabic and English responses based on Accept-Language headers, with complete translations of error messages, validation messages, documentation and developer portal content.

Saudi PDPL and data protection

The Saudi Personal Data Protection Law (Royal Decree M/19), administered by SDAIA, has been in force since September 2023 with implementing regulations. It establishes data protection requirements for processing personal data in Saudi Arabia.

PDPL requirements include consent or other lawful basis for processing, purpose limitation, data minimisation, data subject rights (access, correction, deletion) and security safeguards. PDPL data portability is within the Saudi framework, not equivalent to GDPR controller-to-controller portability. Legitimate-interest exclusions apply specifically to public entities and sensitive data contexts. Health data (Article 23) has additional controls distinct from UAE health-data exemptions. Cross-border transfer of personal data requires SDAIA-approved transfer mechanisms or meeting specific conditions. There is no universal consent or domestic-hosting mandate for all data types.

Sector-specific regulations may impose additional requirements: SAMA cybersecurity framework for financial institutions, Communications, Space and Technology Commission (CST) regulations for telecommunications, National Health Information Center (NHIC) requirements for health data. The specific requirements depend on the entity's sector, the data types processed and the applicable regulatory authorities.

Data residency in Saudi Arabia is not a blanket legal requirement for all data types. The PDPL and sector-specific regulations have specific provisions regarding data transfer and storage. Choosing a Saudi cloud region does not automatically ensure PDPL compliance; compliance requires comprehensive assessment of the full data processing stack.

Risks in Riyadh API projects

SAMA framework evolution. Saudi open banking specifications, participation requirements and scope continue to evolve. API architecture must accommodate framework changes. Investing in adaptable architecture reduces future retrofit costs as specifications are finalised.

ZATCA wave timing. Phase 2 compliance dates are set by ZATCA notification to individual taxpayers. Organisations may receive notification with limited preparation time. Early API architecture preparation reduces compliance risk when notification arrives.

Platform API access processes. Nafath, Absher (government identity platforms), SADAD and mada (SAMA-regulated payment infrastructure operated by Saudi Payments) have specific registration and approval processes. Production access timelines depend on the respective authority's processing. Development can proceed with sandbox and test environments, but production deployment depends on authorisation completion.

Islamic finance product complexity. Islamic banking products have calculation methods, profit distribution mechanisms and accounting treatments that differ from conventional banking. API data models must accurately represent these structures with configured schemas and product-specific calculations. Generic banking schemas may not efficiently address Islamic product requirements without customisation, but this is a configuration and domain-modelling challenge, not a class-wide impossibility. Verification against Shariah board rulings requires domain expertise and Shariah-review coordination.

Arabic text edge cases. Arabic text processing has subtle complexity including Tashkeel handling in search queries, mixed Arabic-English content in structured fields, number formatting variations (Eastern Arabic versus Western Arabic numerals) and address format differences. Edge cases manifest in production with real user input patterns.

Legacy system integration. Saudi enterprises modernising under Vision 2030 often have legacy systems with limited API readiness. Mainframe and legacy ERP integrations require data transformation layers, caching for performance and capacity management to support real-time API access.

API design patterns for Saudi enterprises

Islamic finance data models represent Shariah-compliant products with domain-specific structures: Murabaha cost-plus calculations, Ijara lease schedules, Mudarabah profit-sharing ratios and Takaful contribution models. Generic banking API schemas do not natively model these products; dedicated data models with proper Arabic terminology support accurate representation of Shariah-compliant structures.

Multi-calendar support handles both Hijri and Gregorian calendars for financial calculations, reporting periods, contract dates and regulatory submissions. Some SAMA and ZATCA submissions use Hijri dates while business operations may use Gregorian. APIs must convert between calendars accurately, accounting for the inherent uncertainty in Hijri month boundaries.

Offline-capable API design accounts for intermittent connectivity in remote operations and retail environments. APIs implement local queuing with automatic synchronisation, conflict resolution for concurrent offline edits and ZATCA invoice caching for delayed submission within the reporting window.

API documentation localisation provides complete Arabic technical documentation including API reference, integration guides, error code descriptions and SDK documentation. Arabic developer documentation requires specialised technical writing skills combining API domain knowledge with Arabic technical terminology proficiency.

API architecture for Riyadh enterprises

API gateway centralises authentication, rate limiting, request validation and Arabic content negotiation. For financial APIs, the gateway implements strong customer authentication and enforces consent-based access controls.

Regional cloud deployment with AWS Middle East (Bahrain, outside Saudi Arabia), Azure UAE North (Dubai, outside Saudi Arabia) or Oracle Cloud (Jeddah, within Saudi Arabia) for regional low-latency access. Current Saudi-based availability should be verified for each provider if Saudi data residency is required. Data residency decisions depend on specific PDPL requirements, sector regulations and business needs.

ZATCA integration layer manages invoice submission, clearance status tracking, CSID certificate lifecycle and error handling as a dedicated API service, isolating ZATCA-specific logic from core business APIs.

Idempotency prevents duplicate transactions across payment, ZATCA submission and government integration APIs when clients retry failed requests.

Event-driven architecture implements async communication for ZATCA clearance notifications, payment status updates, government submission results and real-time operational events.

How we deliver Riyadh API projects

Discovery maps SAMA scope, ZATCA compliance requirements, government integration needs and enterprise modernisation architecture. For financial APIs, discovery identifies licensing requirements, Islamic product types and consent management scope. For ZATCA, discovery identifies invoice types, wave notification status and ERP integration requirements.

ZTABS delivers from our Houston, Texas office, remote-first by design. Our cloud services, DevOps capabilities and AI development services support deployment infrastructure. ZTABS also builds custom white-label AI products that clients can brand and resell.

API development cost and timeline

Costs follow our published API development cost guide.

Tier	Typical range	Timeline	What is included
Simple REST API	$8,000 to $20,000	3 to 6 weeks	CRUD endpoints, basic authentication, database integration, simple validation
Mid-complexity API	$20,000 to $50,000	6 to 14 weeks	OAuth/JWT auth, role-based access, webhook system, rate limiting, comprehensive docs
Enterprise API platform	$50,000 to $100,000	14 to 24 weeks	API gateway, versioning, analytics, developer portal, SDKs, sandbox environment
Complex integration API	$100,000+	24 to 40 weeks	Microservices architecture, event-driven, real-time streaming, multi-region, compliance

ZATCA e-invoicing integration with ERP connectivity typically falls in the mid-complexity to enterprise range depending on store count, ERP system and invoice volume. SAMA open banking platforms with Islamic finance products fall in the enterprise to complex integration range.

Choosing an API development partner for Riyadh

Provider type	Strength	Tradeoff
ZTABS (remote-first, Houston office)	Full-stack API, ZATCA/fintech domain, AI capability	Remote-first by design
Saudi systems integrator	Government relationships, Arabic-native	Evaluate custom API depth per engagement
Global consultancy	Multi-jurisdiction expertise	Evaluate Saudi-specific domain depth per team
ERP vendor services	ERP integration specialisation	Evaluate custom API and ZATCA scope per engagement

When custom API development is not what you need

• You need standard ZATCA e-invoicing only. Several solution providers listed in the ZATCA directory (listing is indicative, not ZATCA approval or endorsement) offer turnkey e-invoicing without custom API development.
• You need standard payment processing only. Payment gateway providers offer mada and SADAD integration without custom API work.
• You need Saudi PDPL or SAMA compliance assessment only. We build APIs with compliance architecture; determining specific obligations requires qualified Saudi legal counsel.

See our enterprise software services and AI development services for adjacent needs.