1. Create the inbound endpoint
Open “Connections → REST API” and choose “Receive data in Data Bridge”. Set a name, API version v1 and an identifier such as orders. Identifiers contain 3–64 lowercase Latin letters, digits or hyphens and must be unique among that version's endpoints within your section.
Choose “Immediately after acceptance” or “After flow processing”. For the latter, set the waiting time: a longer run still returns 202. Make Idempotency-Key required to protect against duplicate order submissions. Override only necessary settings on “API limits”; without the override checkbox, current global defaults apply.
2. Define data in the block
Add “API input data” using this endpoint. For tables, choose “Receive data” and JSON, JSON Lines, CSV/TSV, XML or detection from Content-Type. JSON supports an object array and a path such as data.items; nested objects become a.b fields.
Provide a small test dataset and select its own format. Click “Refresh fields”, verify suggested types and mark required values. An order might require orderId, numeric amount and a date in orderDate. Add an orderId unique key or the required field combination. Format checks validate rather than convert values: perform normalization in separate blocks.
The “API input data” block reference describes all properties, behavior without a delivery and mock-data rules.
3. When the request contains files
In “Receive files” mode, configure allowed extensions, file count and reading rules. Supported files include XLSX/XLSM Excel, CSV, delimited TXT, JSON and XML. For Excel, select the sheet and range; for CSV, delimiter and header; for a JSON file, JSON Pointer. Rows from every file in one request form a combined table; optionally include a filename column.
Send files as multipart/form-data, or one file as the request body with its name in X-File-Name or Content-Disposition. For HMAC, sign the actual transmitted body bytes. Test data serves previews and simulation and is never substituted into a working request.
4. Publish and submit a request
Connect the source to checks and a destination, simulate it and publish Production. Grant the API client “Write” for this flow; its owner needs execution permission. Copy the complete URL from the form. The following shows request structure: replace API_KEY, timestamp and signature using your client's HMAC signing rule.
POST /api/v1/inbound/orders?p.Period=2026-10 HTTP/1.1
Host: databridge.example.com
Authorization: Bearer API_KEY
Content-Type: application/json
Idempotency-Key: orders-2026-10-28-batch-001
X-UBC-Timestamp: UNIX_SECONDS
X-UBC-Signature: v1=HMAC_HEX
[{"orderId":"ORD-1042","amount":1250,"orderDate":"2026-10-28"}]Use p.Period only if the flow defines that parameter. If several accessible flows use the endpoint, specify flow=identifier. Unknown parameters are rejected.
5. Track delivery and retries
Keep the delivery ID and Location. Poll GET /api/v1/deliveries/{id} with the same client; use its returned link or GET /api/v1/runs/{run_id} for run details. 202 means accepted, not a completed write. HTTP 200 and delivery status completed do not guarantee business success either: the run may have ended as failed, partial, uncertain or cancelled. Check run.status, run.code, run.message and run.written, then reconcile target data. Delivery status failed indicates failure before creating a run; the cause is in error, and the initial POST returns HTTP 409. A separate delivery GET or an idempotent replay can return HTTP 200 for different current states, so always inspect the response body.
Repeating an identical body with the same idempotency key returns the original delivery and Idempotent-Replayed: true. Different data or a different flow with that key produces 409 IDEMPOTENCY_CONFLICT. When signing is enabled for the client, calculate a new HMAC for a repeated HTTP request: the same signature cannot be reused. Delivery idempotency is not a global transaction across external writes.
6. Callback and diagnostics
Optionally configure a callback address and a separate secret of at least 32 characters. Data Bridge sends POST with delivery JSON, X-UBC-Delivery, event delivery.completed or delivery.failed, timestamp and HMAC. Validate the timestamp and compare signatures in constant time; handle repeated events by delivery ID. The delivery.completed event means that execution finished; determine its outcome from run.status, code, message and written count. No response or a non-2xx response triggers configured retries with doubling delays; redirects are not followed.
Deliberately test an invalid type and duplicate unique key: 422 API_INBOUND_INVALID provides reasons in errors. A missing column can produce API_INBOUND_FIELDS; an oversized body, 413; a full queue, 429 API_INBOUND_QUEUE_FULL. Delivery data is removed after completion, while status and separate audit records have their own lifecycle. Consult the endpoint reference and request log.