Build on Veengu.
APIs for end-user channels, partner integrations, payments and transaction monitoring. A separate analytics database. Source-available reference apps. A staged certification path from sandbox to production. And a continuously delivered platform with a published update policy. This page is an engineering orientation.
Five APIs. Five distinct integration audiences.
Veengu exposes specialised APIs rather than a single generic surface. Each is access-controlled and credentialed per partner or system, so authorisation and rate limits track the integration shape.
A separate analytical database, replicated from Core.
Veengu Analytics DB is a separately licensed module that replicates key operational data and business objects from Veengu Core into a dedicated analytical environment — segregated from the transactional database so analytical workloads never touch the operational hot path.
- Segregated No impact on operational transaction processing
- Optimised Tuned for analytical and reporting workloads
- SQL-native Supports direct SQL queries
- BI-ready Suitable for business intelligence and regulatory reporting
- Synced Regular synchronisation from operational systems — typically every 30 minutes
Integrates with external analytics and BI tools — including Microsoft Power BI, Zoho Analytics, and other SQL-compatible reporting solutions.
Reference frontend source, handed over.
Higher-tier service packages include a source-code handover for selected reference frontends — the customer mobile app, the agent app, and operator and back-office frontend components.
The reference implementations ship with clear schemas, documented contracts, typed interfaces, and opinionated component APIs. The codebase structure is deliberately compatible with modern AI-assisted development and code-generation tools — supporting efficient analysis, onboarding, modification, and acceleration of frontend development.
Recommended path from sandbox to production.
Veengu first delivers the required functionality together with the corresponding APIs and sandbox access. Customers then move through a staged process before any integration is promoted.
The standard sandbox is intended for functional integration testing and regular development. Dedicated performance, load-testing, or isolated testing environments are requested separately and subject to project scope and commercial agreements.
If the customer integrates without direct Veengu delivery participation, the same staged integration → testing → certification → sign-off path is strongly recommended before production rollout.
Development and integration activities must run strictly against sandbox. Never against production.
Continuous delivery, with a documented update policy.
Veengu follows a continuous-delivery model. Before each release, hundreds of automated integration tests run across platform configurations; load and performance testing run in isolated environments; migration and upgrade validation runs automatically; rollouts include automatic rollback. The full process is automated to minimise operational risk and human factor.
- Client applications
- API integrations
- Operational workflows
- Data processing logic
- Hundreds of automated integration tests across configurations
- Load and performance testing in isolated environments
- Automated migration & upgrade validation procedures
- Rollout procedures with automatic rollback
Cloud update flow
- Regular access to latest features & patches
- Stable, continuously tested platform versions
- Reduced operational upgrade overhead
- Minimal downtime and deployment risk
Self-hosted update flow
- Coordinated with customer ops procedures
- Aligned with internal release management
- Exact procedure depends on customer model
Customer-specific integrations not part of the standard platform may have independent release cycles. Upgrade planning, compatibility validation, and operational responsibilities are defined separately between Veengu and the customer.
A distributed, clustered enterprise platform.
Veengu is composed of multiple interconnected services operating as a clustered environment. Deployment requirements differ significantly depending on business use cases, transaction load, reliability and regulatory requirements, infrastructure preferences, and cloud strategy — so there is no universal one-click deployment.
SaaS — Veengu Cloud
Cloud-based environments are generally recommended. They simplify horizontal scalability, high availability, disaster recovery, infrastructure automation, backup, cluster orchestration, and ongoing maintenance.
Self-hosted / on-premise
Supported for customers with regulatory, infrastructure, or operational constraints requiring local deployment. Coordinated together with the customer's internal procedures.
Containerised services on orchestration.
The platform operates as a cluster of containerised services distributed across multiple servers.
Recommended orchestration platforms include Kubernetes and Amazon ECS.
What a typical deployment requires.
Designed for clustered, redundant operation.
- Horizontal scalability
- Multi-node clustered deployments
- High availability configurations
- Automatic service recovery
- Load-balanced traffic distribution
- Isolation between operational components
Even minimal reliable production configurations typically require multiple servers and redundant infrastructure components.
Self-hosted — what the customer owns.
Veengu provides deployment guidance, architectural recommendations, software artifacts, and technical support during deployment activities. Customer-specific architecture and operational procedures remain outside the standard platform documentation scope unless separately agreed.
Ready to integrate?
Send your scope — operator type, target geography, integrations, deployment posture, and timeline — and we'll provision a sandbox tenant during the discovery engagement.