Headless / API
Your frontend. Hamiltonn underneath.
Keep complete control of your customer experience while Hamiltonn provides the platform underneath. Build your own web application, mobile experience, embedded product or server-side integration using supported APIs, authentication and event-driven services.
# sandbox environment curl https://api.sandbox.hamiltonn.cloud/v1/accounts \ -H "Authorization: Bearer sk_sandbox_…" { "data": [ { "id": "acc_7Hw2Rt", "currency": "GBP", "balance": "248124.00" } ], "has_more": false }
What is a headless SaaS platform?
Separate the backend from the customer-facing experience.
A headless SaaS platform exposes software capabilities through APIs instead of requiring every customer to use the provider's frontend.
Hamiltonn Headless / API lets organisations create their own website, web application, mobile app or embedded experience while using supported Hamiltonn backend services underneath. The customer controls the visible product; Hamiltonn maintains the platform services behind the API boundary.
Who it is for
For teams that already know what the frontend should be.
Software companies
Add backend capabilities to an existing product without replacing your interface.
Fintech & digital assets
Create custom financial, wallet, exchange or custody experiences on Hamiltonn services.
Enterprise product teams
Integrate Hamiltonn into an existing digital architecture and identity ecosystem.
Agencies & developers
Build differentiated client experiences around reusable Hamiltonn infrastructure.
Developer surface
A controlled interface between your application and our platform.
Customer applications integrate through supported external interfaces rather than direct access to private Hamiltonn services or production databases.
REST APIs
Resource-oriented endpoints with consistent errors and pagination.
Webhooks
Signed events with retries for everything that happens.
Authentication
Scoped API keys per environment; rotate without downtime.
Sandbox
A safe environment that mirrors production behaviour.
Versioning
Breaking changes only behind explicit version bumps.
Environments
Sandbox and production, cleanly separated keys and data.
Server-side policy
Approvals and limits enforced below your code.
Audit
API activity logged and reviewable.
Access control
Every request has an identity, tenant and permission boundary.
External applications authenticate before calling protected Hamiltonn services. The platform resolves the relevant organisation or tenant context, validates the request and enforces server-side authorisation rather than trusting frontend code.
Privileged credentials belong in secure server-side environments — not in public browser bundles or distributed mobile applications.
- Authentication — identify the calling user, service or integration.
- Authorisation — enforce which resources and actions are permitted.
- Tenant context — keep requests associated with the correct organisation.
- Auditability — keep important integration activity traceable.
API design
Predictable interfaces are easier to build on.
Hamiltonn's public API layer is designed around consistent resource patterns and controlled change rather than exposing undocumented internal application endpoints.
Versioning
Public interfaces evolve through explicit version and compatibility rules.
Errors & request IDs
Structured errors and traceable request identifiers help developers investigate integration behaviour.
Pagination & filtering
Collection APIs remain usable as customer data and activity grow.
Idempotency
Retry-sensitive financial and operational actions can be protected against unintended duplicate execution.
Event-driven integration
React when something changes.
Where supported, Hamiltonn webhooks let customer systems respond to platform events without continuously polling APIs. Event delivery can support signatures, unique event identifiers, retry handling and duplicate-safe consumer patterns.
{
"type": "project.created",
"data": { "id": "prj_example" }
}Build safely
Separate integration work from live operations.
Hamiltonn's developer model supports non-production integration patterns before live production access, with environment-specific credentials and documentation for supported services.
Sandbox / development
Experiment with supported APIs and workflows away from live customer operations.
Staging / UAT
Validate customer journeys, integrations and events before production where the deployment includes a pre-production environment.
Developer documentation
Authentication, endpoints, request/response examples, errors, webhooks, changelog and integration guidance.
Application patterns
Web, mobile, embedded and server-to-server.
Web applications
Build a browser experience in the framework and design system your product team prefers.
Mobile applications
Use supported Hamiltonn services behind native, cross-platform or PWA experiences.
Embedded experiences
Add selected Hamiltonn capabilities inside an existing product rather than replacing the whole application.
Backend-to-backend
Connect customer systems for provisioning, synchronisation, reporting and operational workflows.
Product APIs
One developer platform across specialist product families.
A custom application can use supported capabilities from Financial Cloud, Business Cloud and AI Cloud — individually or in combination.
Financial Cloud
Customers, onboarding, accounts, wallets, transactions, statements and digital-asset workflows.
Business Cloud
Customers, leads, quotations, projects, workers, attendance, scheduling and documents.
AI Cloud
Agents, conversations, knowledge, email and workflow actions connected to business systems.
Security boundary
APIs, not production database credentials.
The standard Headless / API model does not expose unrestricted direct access to Hamiltonn production databases or private internal services. Customer integrations use supported public interfaces so platform integrity, tenant boundaries and upgrade compatibility remain enforceable.
Protect secrets
Keep API credentials, private keys and privileged tokens out of public repositories and frontend bundles.
Public vs internal APIs
Customer integrations should rely on documented external interfaces, not undocumented internal endpoints.
Data minimisation
Request and replicate only the information the customer application genuinely needs.
Combine models
Your frontend can still be white-labelled and dedicated.
Headless + White Label
Your entire visible interface is your brand while Hamiltonn remains behind the API boundary.
Headless + Dedicated
Use your own frontend with a customer-specific Hamiltonn backend environment.
Headless + Managed tools
Use a custom customer frontend while retaining selected Hamiltonn-managed operational interfaces where appropriate.
Implementation
From API evaluation to production.
Define use case
Map product capabilities, data flows and user journeys.
Review services
Identify supported APIs, authentication and events.
Build integration
Develop your frontend and secure server-side integration.
Test
Validate permissions, errors, retries, idempotency and webhooks.
Production readiness
Separate credentials, logging, alerts and operational responsibilities.
Launch
Move the approved integration to the production environment.
Frequently asked questions
Does headless still count as white-label?
Yes. Everything the platform produces — emails, documents, notifications — still carries your brand, even when the frontend is entirely yours.
Can I mix models?
Commonly done: your customer-facing app on the API, with the managed admin portal for your operations team.
Where do I get keys?
Request sandbox access and we provision keys with the walkthrough — see the Developers page.
What is Hamiltonn Headless / API?
It is the Hamiltonn deployment model for organisations that want to build their own customer-facing frontend while using supported Hamiltonn backend services through documented interfaces.
Can I build a mobile app on Hamiltonn?
Yes. Supported Hamiltonn APIs can sit behind mobile application architectures. Privileged server credentials should remain outside distributed mobile code.
Can I access the Hamiltonn production database directly?
Not under the standard Headless/API model. Customer integrations use supported API interfaces rather than unrestricted database access.
Can I combine multiple Hamiltonn products through APIs?
Yes, where the relevant product services are exposed and technically compatible. A customer application can combine capabilities across Financial, Business and AI Cloud.
Can Headless be combined with Dedicated Enterprise?
Yes. Enterprise customers can combine their own frontend with a dedicated Hamiltonn backend environment.
Build your experience on Hamiltonn.
Control the layer your customers see while Hamiltonn provides the reusable platform services underneath.