Documentation · Cube2
Welcome
Cube2 turns financial APIs into AI-readable infrastructure — capturing the operational knowledge developers and AI agents need to integrate and execute correctly, beyond what a raw API specification describes.
What Cube2 is
A financial API exposes endpoints, schemas, and status codes — but the knowledge to use it correctly lives in docs, code, support threads, and human expertise. Cube2 discovers, verifies, and structures that knowledge into a machine-readable layer for developers and AI agents.
A specification gives you
- Endpoints and schemas
- Field names and types
- Status codes
Cube2 adds
- Which call comes first, and why
- What each field really expects
- Which validations fire
- How errors recover
Start here
Documentation · Cube2
Cube2 Solution
Cube2 adds a layer of verified knowledge on top working APIs — the parts a spec leaves out but an integration actually depends on.
What Cube2 adds
- Verified behavior — what the core actually accepts, rejects, and requires. Specifications often mark fields as optional that the platform truly enforces, or list values that are not really accepted. Cube2 records what the core actually enforces, so requests succeed on the first attempt instead of through trial and error.
- Workflow context — how individual operations connect into complete business processes. The specification lists operations in isolation; Cube2 shows how they combine into real journeys — such as onboarding a customer end to end — including which step must run before another and how the result of one call feeds the next.
- Business semantics — clearer meanings for vendor-specific fields and structures. Vendor names and codes describe how the platform stores data, not what it means for the business. Cube2 translates them into clear, business-oriented terms so teams can map their own data without decoding vendor jargon.
- Specification drift — where the documentation is incomplete, inconsistent, or misleading. Over time, documentation and real behavior drift apart. Cube2 flags the places where a field's name, type, or description does not match what it actually does, so those traps are known up front rather than discovered in production.
- Authentication behavior — the real access and security requirements. Beyond naming the security scheme, Cube2 captures what access actually requires in practice: how credentials are obtained, which scopes apply, and how sessions behave across a workflow.
- Idempotency and retries — how duplicate requests and repeated operations behave. Networks fail and requests get retried. Cube2 documents which operations are safe to repeat, which create duplicates, and how to retry safely — so a retry never produces a second record or a double action.
- Identifier lifecycle — how identifiers are created, related, and reused. Identifiers are produced by one call and consumed by many others. Cube2 explains where each identifier comes from, which are generated by the platform versus supplied by the caller, and how they tie the steps of a process together.
- Operational limits — practical constraints such as pagination and safe request volumes. The specification rarely states the limits you hit in practice. Cube2 records constraints like how results are paginated and what request volumes are safe, so integrations are designed within real boundaries rather than discovering them under load.
- Error intelligence — how failures are returned, interpreted, and normalized. Errors come back in platform-specific shapes that are hard to read. Cube2 explains how failures are returned and what they mean, and normalizes them into a consistent form so error handling stays predictable across operations.
In practice, Cube2 turns a technical API contract into reliable, business-ready integration knowledge.
Tools
Cube2 delivers this knowledge through a set of tools an AI development tool calls, grouped by stage — discover, map, generate.
| Tool | What it does |
|---|---|
| Discover | |
start_guide | Session entry point; starts the guided integration flow. |
list_workflows | Maps a business intent to the correct ordered workflow chain and its steps. |
get_operation | One operation's field contract: fields, required flags, tested values, business meaning. |
get_api_behavior | Verified API behavior: auth, environments, identifiers, idempotency, error codes, flows. |
get_domain_values | Reference/enum tables — class codes, titles, address types, identification types. |
| Map | |
guide_attribute_mapping | Interactive step-by-step mapping driver (start → identify → refine → generate). |
map_attributes | Returns the full attribute-mapping instructions — the core mapping process. |
build_mapping_tables | Renders matched request/response attributes into formatted tables plus a summary. |
add_required_attributes | Adds required and conditionally-required fields to the mapping. |
| Generate | |
classify_attribute_mapping_type | Classifies each mapping into 6 types (Direct, Format, EnumLookup, ReverseEnum, DynamicLookup, MissingValue) with a transformation strategy. |
generate_code | Turns a finished mapping into production integration code. |