Set up data exchange between systems
An API lets applications exchange data automatically. Receive orders, check them against your rules and send the results to other systems. You choose the data, response format and access rules.
Receive · prepare · publish
One managed route for receiving, validating, transforming and delivering data
Your own endpoints with the fields, parameters and freshness consumers need
Generated documentation, useful responses and configurable access for each consumer
Let the sender see the error. Before a write.
Define a schema, required values and a unique key. The selected error policy determines what happens to an invalid request.
/api/v1/inbound/orders[
{
"orderId": "ORD-1042",
"amount": "abc",
"orderDate": "2026-10-28"
}
]A field needs correction
In the first row, amount contains text instead of a number. Detailed response mode identifies the field, row and reason.
code: API_INBOUND_INVALIDUnder this policy, the invalid request does not start the flow.Documentation that matches your configuration.
Methods, fields, access rules, examples and responses — in one reference for the integrator.
Receive data from other systems
Portal orders, branch stock updates and partner files can enter an agreed flow immediately. Create a REST API connection with the “Receive data in Data Bridge” direction, define its version and address, then add an API input block. After publication, each accepted delivery starts the Production flow. Request bodies support JSON, JSON Lines, CSV/TSV and XML; file mode reads Excel XLSX/XLSM, CSV, delimited TXT, JSON and XML. Configure the record path, worksheet, range or delimiter for the source. Partners supply familiar formats; your team controls processing.
- Accept a request-body table or files through multipart/form-data
- Combine rows from one request’s files into a processing table
- Version the endpoint address and execute published flow logic
Check data as soon as it arrives
Provide sample data to generate fields and suggested types. Review text, integer, decimal, date, date-time and Boolean fields; mark required values and single-field or composite unique keys. An order number plus line number, for example, should not repeat within one delivery. This checks conformity without automatically changing values. Next, Column mapping defines field names, selection and order; reference-data joins enrich records; Data cleansing and control applies ordered rules. An empty amount can become a numeric zero, while a negative amount can stop processing with DATA_QUALITY. Normalization, row rejection and stopping are explicit decisions matched to your process.
- Entry checks cover formats, required values and duplicate keys within one request
- Use mapping, reference data, formulas and quality rules before writing
- Preview and simulate with sample data that is never substituted into production deliveries
Define the business contract
Identify senders, consumers, required fields, success criteria and freshness requirements.
Build and test the flow
Configure the schema, mapping and quality rules. Simulate valid and invalid examples.
Grant appropriate access
Assign client rights, limits and a key, or deliberately enable public publication.
Publish and connect the consumer
Provide documentation access, verify Production, test delivery or retrieval and monitor the audit.
Explain what needs to be corrected
Invalid entry values can return HTTP 422 API_INBOUND_INVALID with row, column, field, value, error type and reason; duplicate-key details identify the fields and original row. Choose full rejection with details, a summary, or acceptance of valid rows only. Responses list up to 100 errors plus overall counts. Asynchronous HTTP 202 supplies a delivery identifier and Location for tracking. Completion-wait mode returns the finished result or 202 when its wait expires. Inspect run.status, run.code, run.message and written counts: HTTP 200 and delivery.completed alone do not guarantee flow success. Failure to create a run differs from a business-rule failure during execution.
- Missing columns use API_INBOUND_FIELDS; invalid values use API_INBOUND_INVALID
- Flow validation errors such as DATA_QUALITY appear in run.code and run.message
- Signed callbacks report delivery completion; check the enclosed run outcome separately
Read and send data through APIs
Data Bridge can call an external service or send it a flow’s result. Read CRM orders, enrich them with ERP codes and deliver a consistent batch to finance. Reading supports GET or POST, response parsing and pagination through next-links, Link headers, page numbers or offsets. Sending supports POST, PUT or PATCH, one request per row or batches. Choose JSON, XML, form data or CSV according to the receiver’s contract. External authentication uses that service’s credentials: Basic, Bearer, a header API key or OAuth 2.0 client credentials. An open service can be accessed without authentication.
- Configure paths, parameters, headers, format and batches for the destination
- Map the outgoing structure instead of manually rearranging fields
- Reach approved internal APIs through a configured UBC Agent
Receive · prepare · publish
Share the data each application needs
A portal needs stock by warehouse, an application needs dated exchange rates, and a partner needs an available assortment. Combine sources, apply rules and connect the result to API data publication. Consumers receive agreed fields in JSON, JSON Lines, CSV or XML. Configure text, numeric or date parameters: individual values, lists, ranges, permitted bounds and required inputs. An endpoint can serve stored results with an age check or run the flow on demand. Longer calculations return 202 API_RUN_PENDING and a next address that continues waiting for the same run. Completed results can be reused for a configured period.
- Filter prepared rows or pass values into flow run parameters
- Read consistent result pages; use ETag and 304 for unchanged data
- Failed on-demand runs return 502 API_RUN_FAILED; stale stored data returns API_DATA_STALE
Give developers a ready reference
Technical HTML documentation is generated from saved endpoint settings, block configuration and sample data. It describes the full address, format, fields, required values, unique keys, parameters, responses, errors and effective limits. Quick-start instructions and curl, Postman and Python examples help reproduce the first request; HMAC examples appear when applicable. Save configuration changes and reopen the page to refresh the contract. Check its status against Production: a saved draft is not a published change. Access requires a flow editor or a user with the appropriate documentation permission and flow visibility. Client secrets are never included.
- Examples follow the actual request format and publication mode
- Users sign into Data Bridge; an API key alone cannot open HTML documentation
- Public data publication does not make technical documentation public
Receive · prepare · publish
Set up several layers of protection
For protected endpoints, issue a separate API key to each integration and use HTTPS. Send keys in Authorization: Bearer or X-API-Key, never in URLs. A key belongs to a user: its Read and Write permissions for selected flows cannot exceed that owner’s current rights. Configure expiry, allowed IPv4/IPv6 addresses or CIDR networks, request limits and HMAC-SHA256, enabled by default. Signatures cover time, method, path with query parameters and the body hash. Clock differences are limited to five minutes, and signature replay is rejected. Rotation replaces a key; disabling the client stops access. Match controls to each partner.
- 401 identifies key, expiry or signature issues; 403 covers address, user status or rights
- Client and workspace request limits return 429 with Retry-After
- An IP is temporarily blocked after 30 failed authentications within 15 minutes
For protected API endpoints
Choose private or public access
Keep internal metrics, partner-specific stock and personal results behind keys and permissions. For an open reference list, public catalogue or information widget, enable the separate public-publication setting. After explicit confirmation, anyone with the address can read it without a key, signature or flow-rights check. CORS allows requests from other websites, so a public widget need not contain a secret. Per-IP and overall API limits, pagination, configured freshness checks and auditing remain. Only this endpoint becomes public: inbound requests, history, other results and documentation retain their own access controls. Select fields deliberately before enabling access.
- Protect agreed business integrations with managed client keys
- Use public addresses for data suitable for unrestricted access
- Serve a widget from stored results refreshed on a schedule
Receive · prepare · publish
Find the cause of an error in the history
Idempotency-Key prevents another run when the same delivery is repeated; a changed body with the same key produces a conflict. Each repeated HTTP request needs a new HMAC signature. Outbound writes are not automatically retried when the external service might already have performed them: a lost response requires destination reconciliation. Configure request size, queues, frequency, timeouts and callback retries. Use the API audit to correlate addresses, clients, time, status and runs. Body retention is controlled separately: after delivery data is cleared, an audit copy may remain according to its settings.
- Prevent duplicate delivery runs without claiming a transaction across external systems
- Test success, invalid fields, duplicate keys and limits before rollout
- Use a new endpoint version for an agreed migration to a changed contract
Your questions, answered.
How to connect your data, manage access and get started.
Do I need to program a separate API server?
Configure endpoints and processing blocks in Data Bridge. External applications send HTTP requests using the agreed contract.
Does type validation automatically repair values?
No. The entry schema validates; separate blocks transform. Unique keys detect duplicates within one request, not across historical deliveries.
Does HTTP 202 mean the data has been written?
No. Check run.status and the destination result after completion. delivery.completed indicates completion, not necessarily success.
How do HMAC and Idempotency-Key differ?
HMAC validates individual requests and rejects signature replay. Idempotency-Key links repeated deliveries to the first run. Retries need new signatures.
Can consumers read data without a key?
Yes, through explicitly enabled public publication. Anyone with the address can read it; documentation and other API routes remain controlled.
Does every read fetch the sources again?
No. Choose stored results with freshness control or execution on request, with configurable waiting and result reuse.
Let’s start with your task.
Tell us which data you need to connect. We will explain how it works and show you an example.
Bring your challenge. See a way forward.
Sources, rules and outcomes — let’s build the conversation around your workflow.