Integrating
Every external system sits behind a protocol with two implementations: a stateful simulator we develop against, and a real adapter written to your specification. Adopting a real integration is one class, not a rewrite.
What we bring
Idempotency on every instruction
Mint, transfer, lien, release and payment calls all carry a key. A retry after a lost response returns the original outcome instead of acting twice. A lien placed twice is a lien that will not lift.
Circuit breakers and backoff
A failing dependency stops being called rather than consuming every worker. Retries use exponential backoff with jitter, so recovery does not recreate the spike that caused the outage.
An audit record of every call
What we sent you and when is answerable from our own records, not by asking you to check yours.
Compensation, not hope
Every instruction with an external effect has a named reversal, tested by failure injection rather than described in a document.
One answer we particularly need. If a call succeeds on your side and the response is lost, we must be able to ask what our idempotency key produced. Without that lookup an in-doubt instruction cannot be resolved honestly: we would have to guess, and guessing is how a real transfer survives a settlement we recorded as unwound.
Partner questionnaire
These are the questions we need answered by vaults, depositories and lending institutions before an integration is designed. They are published rather than sent as a form so you can see the scope before committing to a call.
API and integration capabilities
- Which API protocols do your core systems support today — REST, SOAP, gRPC, FIX?
- Do you offer developer documentation, a sandbox or UAT environment, and test credentials?
- Does your system support webhooks or event-driven callbacks for real-time status?
- Can you enumerate holdings, or only answer per-identifier lookups?
Security and compliance
- What authentication do you require on inbound requests — OAuth 2.0, API keys, mutual TLS?
- Do you require site-to-site VPN, dedicated lines, or static IP allowlisting?
- What data residency, privacy or audit-logging constraints apply when we interact with your system?
- Do you sign your responses, and if so with what key material and rotation schedule?
Operational logistics
- For banks: what cadence or trigger do you prefer for live bullion valuation, and do you mandate a specific pricing feed?
- For vaults: are digital lien instructions executed immediately via API, or in a scheduled batch window?
- What are your cut-off times, and what happens to an instruction received after one?
Failure and recovery
- What is your protocol for scheduled maintenance, rate limits and failover?
- If an instruction succeeds on your side but the response is lost, can we look up its outcome by the idempotency key we supplied?
- How should a mid-flight failure be resolved — for example, a lien placed successfully while the funding leg then fails?
What we will hand over
- An OpenAPI specification and Protobuf definitions for the service surface.
- A sandbox integration guide, with the simulators available for your own testing.
- The permission matrix and the test report showing it is enforced.
- Failure-injection drill results, each recording what was injected and what was observed.
- Load-test percentiles with the measurement boundary stated.
- The audit chain specification and the public key, so you can verify our exports without us.
Open dependencies
Two things are outstanding and are tracked rather than assumed: IIDI’s API specification, and the IFSCA filing schemas. Both are isolated behind a single interface, so the work of adopting the real ones is bounded and known. We would rather say that than present a placeholder as a finished mapping.