SOFTWARE

IntegREST

Serve data as a REST API by declaring SQL instead of writing integration code, and keep every call on record.

The management console

IntegREST declared API management list populated with synthetic demo data

Declared APIs

.media-rotator--interactive{display:none!important}

IntegREST SQL editor showing a synthetic customer table and a read-only SELECT statement — Read-only SQL editor

IntegREST query SQL editor with declared parameters bound in the SELECT and preview rows returned from the target database — Query preview

IntegREST REST call declaration showing a synthetic external API and XML request template — REST call declaration

Full IntegREST API test screen with masked keys and synthetic request values — API testing

IntegREST API call history populated with synthetic systems and call records — Call history

IntegREST audit log populated with synthetic users and hashes — Audit log

These are screens from the current IntegREST management console. Accounts, connection addresses, keys, IP addresses, and UUIDs are masked or replaced with synthetic demo data before publication. The console UI is in Korean.

DATA INFRASTRUCTURE · MIGRATION

From data movement to operational integration

01 · DBridge

High-volume migration and loading

Use either a database or a declared API as the source, then migrate or load the data into a target database with a multiprocess batch engine.

Explore DBridge →

02 · IntegREST

Request-driven queries and REST relay

Serve database queries and external REST calls between business systems as declared APIs, with evidence of how each call was processed.

From declaration to operational evidence

Declared API design

Manage the API ID, caller-facing path, request parameters, response shape, and encryption policy as one declaration.

Read-only database queries

Write one SELECT statement alongside database metadata and declaration parameters, then run static checks and preview it against the target database.

External REST relay

Combine a connection profile, HTTP method, XML or JSON request template, and response paths into a single request-response REST call.

Contract-level testing

Call the same caller-facing endpoint, then inspect status, duration, row count, encryption results, and reproducible request examples.

Operational evidence and reconciliation

Query received calls and planned or completed outputs by declaration, then review processing success separately from ledger consistency.

Audit record integrity

Keep management and relay actions in linked audit records and verify integrity by date.

DETAIL VIEWS

Readable design, test, and audit views

Full screens establish the operating context; close-ups make request contracts and evidence legible.

IntegREST query SQL editor dialog showing a SELECT with bound declared parameters, the schema panel, and preview rows from the target database — **Declared parameters bound in SQL** Bind declared parameters such as {{startDateTime}} inside the SELECT, then check the returned rows and elapsed time against the target database before saving. The side panel lists tables and columns.

Close-up of IntegREST API testing with masked authentication data and synthetic request parameters — **Test the request contract as served** Review the calling system, masked keys, data types, values, and input rules in one place.

Close-up of an IntegREST audit log populated with synthetic actors and hashes — **Verify daily audit links** Connect actions, results, targets, and synthetic hashes to review the audit-chain state.

Close-up of five synthetic call-history rows in the IntegREST API call summary — **Read call evidence in one table** See the declaration, caller, request path, completed outputs, and processing result together.

Current execution scope

DB QUERY

Read-only database query

Run a query with declared request values and return it in the configured response shape.

REST RELAY

External REST relay

Apply declared request templates and response rules to relay an external REST call.

The current scope covers read-only database queries and single-call REST relay.

Evidence boundaries for closed networks

API keys issued per calling system — plaintext shown once, with only a SHA-256 fingerprint retained
Received calls and planned or completed outputs managed as append-only operational evidence
Call evidence stores JSON request bodies with API keys masked; raw responses, query strings, and secret headers are not stored
Retention periods for call, audit, and reconciliation records managed in system settings
Management console with no dependency on external CDNs or runtime downloads

Considering Cubiware for your organization?

We will guide you through setup and rollout tailored to your requirements and operating environment. Reach out for a demo or a proposal.