Hub Technologies API (1.0.0)

Returns an empty response with HTTP 400. Exists as a catch-all root route; not intended for client use.

Returns an empty response with HTTP 400. Exists as a catch-all root route; not intended for client use.

Returns a plain-text confirmation that the service is running. No authentication required.

Creates or replaces the Elasticsearch index (with alias and mapping), lifecycle policy, and index template used by the transaction monitoring module. Idempotent -- safe to call multiple times.

Accepts a search payload, queries Elasticsearch for matching transactions, and streams the results back as a CSV file attachment. The response uses chunked transfer encoding.

Performs a paginated search against the Elasticsearch transaction index. Supports cursor-based pagination via the cursor_id parameter for efficient deep paging.

Appends a new batch of entity data to an existing job identified by job_id. The payload is validated, uploaded to cloud blob storage, and a background thread monitors the downstream processing service. Returns HTTP 202 with the job_id once the batch is accepted.

Functionally identical to PUT on this path. Submits a batch of entity data under an existing job_id.

Creates a new ingestion job, validates the payload against entity-type rules, uploads the data to cloud blob storage, and kicks off background processing. Returns HTTP 202 with the newly generated job_id. Supports optional master-config chunking via is_mc_enable and mc_chunk_size.

Functionally identical to PUT on this path. Creates a new ingestion job and submits entity data for processing.

Accepts a JSON Patch-style array of operations (op, path, value) to partially update an entity record. The entity is identified by entity_type, id, source_system, and business_unit query parameters. Creates a new background job for the patch operation.

Queues an entity deletion through the standard ingestion pipeline. The entity is identified by entity_type, id, source_system, and business_unit query parameters. A background job is created and the deletion is processed asynchronously.

V2 ingestion endpoint that validates and transforms entity data before uploading to blob storage and inserting a message into the processing queue. Supports upsert and overwrite modes. For account entities, a reference_entity_type field is required in the payload.

V2 patch endpoint that validates patch operations, transforms them through the ETL execute pipeline, and uploads the result for asynchronous processing. Each patch operation object in the array is enriched with the entity ID, source system, and business unit before processing.

V2 delete endpoint. Validates the delete request, passes it through the ETL execute pipeline for transformation, and queues the deletion for asynchronous processing.

Queries the request metadata table for the given job_id and returns a summary of each batch's current processing status. If a batch has failed or partially succeeded, the response includes a link to the invalidated records file.

When called without a job_id, this endpoint always returns HTTP 400 instructing the caller to provide a valid job_id.

Looks up the pipeline metadata table by file_name and returns the current processing status, counts of transformed and validated records, and a link to any invalidated records.

Proxies the request to the downstream ETL service to fetch the fully processed entity record. Requires entity_type, id, and optionally source_system and business_unit to uniquely identify the record.

Returns a paginated list of contacts associated with the given referenceId. Results are sorted by firstName. An optional JSON-encoded filters parameter allows filtering by firstName, lastName, position, email, phoneNumber, isMainContact, sourceSystem, businessUnit, or contactType. The contactType field in the response is enriched with display labels from the lookup table.

Accepts an array of contact objects. If a contactId is present in an item, the corresponding record is updated; otherwise a new contact is created with an auto-generated UUID. At most one contact per referenceId may have isMainContact set to true. The endpoint validates required fields (referenceId, firstName, lastName, phoneNumber) and data types before persisting.

Deletes one or more contact records identified by a comma-separated list of contactId values. If any contactId does not exist, the request is rejected with HTTP 404 before any deletions occur.

Retrieves the contact record matching the given contactId. The contactType field is enriched with display labels from the lookup table. Returns an array (typically with zero or one element).

Returns all contact records for the given referenceId without pagination. Supports the same optional filters parameter as the paginated list endpoint. Intended for bulk export workflows.

Synchronously creates a primary entity record (person, organization, account, payment, or product). The request body is validated against the JSON schema for the given entity type. The primaryEntityData object must contain all required attributes for the entity type. An optional primaryEntityExtraData object may contain flat key-value pairs of additional data.

Synchronously updates a primary entity record. Only the businessUnit, sourceSystem, and primaryEntityID fields are required; all other primaryEntityData fields are optional and only provided fields will be updated. Validated against the entity type's JSON schema with relaxed required-field rules.

Synchronously deletes a primary entity identified by the combination of businessUnit, sourceSystem, and primaryEntityID query parameters. Exactly these three query parameters must be provided.

Synchronously creates a related (weak) entity linked to a primary entity. The relatedEntityPath identifies the type of relationship (e.g. address, identifier, contactpoint). Date fields like birthDate and incorporationDate are automatically converted from dd-MMM-YYYY to YYYY-MM-DD format if needed.

Synchronously updates or deletes a related entity identified by its relatedEntityHash. The operation field must be either 'UPDATE' or 'DELETE'. For UPDATE operations, only the provided relatedEntity fields are modified. For DELETE operations, the related entity is removed from the primary entity.

Creates a new identifier record (e.g. passport number, tax ID) linked to an entity via reference_id. Required fields are reference_id, identifier_type, and identifier_value. The created_date and updated_date are set to the current UTC timestamp automatically. An audit log entry is created upon successful insertion.

Accepts an array of reference_id values and returns all identifier records grouped by reference_id. Reference IDs with no matching identifiers appear as empty arrays in the response. Note: this endpoint returns HTTP 200 for all outcomes including validation errors and auth failures.

Updates an existing identifier record. Only the fields provided in the request body are modified; omitted fields remain unchanged. Each changed field generates an individual audit log entry capturing the old and new values. The updated_date is set to the current UTC timestamp automatically.

Permanently removes an identifier record. The updated_by and updated_by_username query parameters are used for audit logging purposes only. Note: this endpoint returns HTTP 200 for all outcomes including not-found and auth failures.

Creates a new free-text comment record linked to an entity via reference_id. If a record with the same reference_id already exists, it is updated (upsert behavior). Required fields are reference_id and comment. An audit log entry is created only for new records, not updates.

Accepts an array of reference_id values and returns the matching text records keyed by reference_id. Since text records have a unique reference_id, each key maps to a single object (or null if no record exists). Note: this endpoint returns HTTP 200 for all outcomes including validation errors and auth failures.

Updates an existing text record. Only the fields provided in the request body are modified. Each changed field generates an individual audit log entry. The updated_date is set to the current UTC timestamp automatically.