API Framework

Every compliance control — exposed as a stable, versioned API.

JWT-secured REST endpoints covering customer onboarding, transaction scoring, case management and the RBA engine — documented in OpenAPI, tested in sandbox, audited on every call.

Authentication Flow

JWT bearer over HTTPS — three calls to first traffic.

A single POST /api/Auth/login exchanges your tenant code + credentials for a session JWT. Every subsequent call carries it as Authorization: Bearer <token>. Tokens are short-lived; re-authenticate when they expire.

Step 01
Client app
Holds the tenant Code, User_Name and Password issued by LiveEx Shield.
Step 02
POST /api/Auth/login
Send credentials as JSON over HTTPS.
application/json
Step 03
JWT issued
Server returns signed bearer token tied to the session.
HTTP 200
Step 04
Authorized API call
Every request carries Bearer <token>.
Step 05
Validation
Signature + expiry + tenant claims verified per call.
Step 06
Response envelope
Standard JSON shape — same schema every time.
Endpoint Reference

Four endpoint groups, twenty-one endpoints — covering every compliance touchpoint.

Each group below is a logical surface area. Customer Integration handles KYC and case lifecycle; Transaction Integration covers TMS scoring and listings; Utilities expose rules and reference data; Auth governs every session.

Auth
1 endpoint
  • POST /api/Auth/login
Customer Integration
9 endpoints
  • GET /api/Customers/status/{clientNumber}
  • POST /api/Customers/save
  • POST /api/Customers/validate
  • PUT /api/Customers/name
  • POST /api/Customers/documents
  • GET /api/Customers/documents/{clientNumber}
  • POST /api/Customers/case-clear
  • GET /api/Customers/case-status/{clientNumber}
  • GET /api/Customers/listing
Transaction Integration
6 endpoints
  • POST /api/Transactions/save
  • GET /api/Transactions/status/{trIdDisplay}
  • GET /api/Transactions/case-status/{trIdDisplay}
  • POST /api/Transactions/tms-details
  • PUT /api/Transactions/manual-status
  • POST /api/Transactions/listing
System Utilities
6 endpoints
  • GET /api/Utilities/last-update
  • GET /api/Utilities/active-rules
  • POST /api/Utilities/validate-ip
  • GET /api/Utilities/occupations
  • GET /api/Utilities/business-activities
  • GET /api/Utilities/countries
Standard Response

Every endpoint returns the same envelope.

Whether you saved a customer, queried a transaction or validated an IP — the response shape is identical. Your client only ever has to parse one schema.

// Sample response envelope { "message": "Customer created successfully", "isError": false, "messageCode": "SUCCESS", "messageDetails": "Client TRCUSTOMER_002 stored", "data": { "clientNumber": "TRCUSTOMER_002", "riskScore": 2.4, "riskBand": "MEDIUM", "sanctionsHit": false, "pepFlag": false } }
  • message
    Human-readable statusShort summary line, suitable for logs and analyst-facing UI surfaces.
  • isError
    Boolean error flagOne-glance success/failure check — bypasses parsing status codes when you just need the verdict.
  • messageCode
    Machine-readable codeSUCCESS / ERROR / VALIDATION_FAILED / NOT_FOUND. Use in switch logic, not regex.
  • messageDetails
    Diagnostic contextValidation reasons, field names, downstream error references. Safe to surface to your support team, not to end users.
  • data
    Primary payloadThe actual resource — customer record, transaction TMS-details, listing array, etc. Schema varies by endpoint; envelope does not.
Quickstart

From zero to first scored transaction in four curl calls.

Real working calls against the LiveEx Shield TMS API. Drop them into your terminal, replace the credentials with the sandbox keys we issue, and you have a working integration loop in under five minutes.

1 · Login 2 · Save customer 3 · Score transaction 4 · Check status
# 1 · Exchange credentials for a JWT curl -X POST https://api.liveexshield.co/api/Auth/login \ -H 'Content-Type: application/json' \ -d '{"Code": 9001, "User_Name": "admin_demo", "Password": "***"}' # 2 · Save a natural-person customer curl -X POST https://api.liveexshield.co/api/Customers/save \ -H 'Authorization: Bearer $TOKEN' \ -H 'Content-Type: application/json' \ -d @customer.json # 3 · Submit a transaction for TMS scoring curl -X POST https://api.liveexshield.co/api/Transactions/save \ -H 'Authorization: Bearer $TOKEN' \ -H 'Content-Type: application/json' \ -d @transaction.json # 4 · Poll the TMS verdict for that transaction curl -X GET https://api.liveexshield.co/api/Transactions/status/TR-2026-00482 \ -H 'Authorization: Bearer $TOKEN'
HTTP Status Codes

Status semantics, not surprises.

The API returns standard HTTP status codes. The envelope above is your detail surface; the status code is your routing surface.

200
OK
Successful request. Inspect data for the resource and messageCode for downstream signals (e.g. risk band).
201
Created
Resource persisted (customer, transaction, document). Envelope carries the new identifier.
400
Bad Request
Validation failed — messageDetails names the offending field. Fix and retry.
401
Unauthorized
Missing, expired or invalid JWT. Re-call /api/Auth/login and retry with the fresh token.
403
Forbidden
Token is valid but lacks permission for that endpoint or tenant. Request a scope upgrade.
404
Not Found
Resource (clientNumber, trIdDisplay, document) doesn't exist in this tenant.
429
Rate Limited
Per-key rate limit exceeded. Honour the Retry-After header and back off.
500
Server Error
Platform-side fault. messageDetails includes a trace ID — quote it when you contact support.
Risk-Based Assessment

Every validation call returns a full RBA breakdown.

The /api/Customers/validate and /api/Transactions/tms-details endpoints don't just return a number — they return the component risks, the mitigation scores, and the residual risk the engine computes from them.

Geography Country of residence + transaction corridor
3.9 / 5
Customer Type PEP / DNFBP / standard band
3.1 / 5
Product & Channel Cash-intensive, cross-border, online-only
2.7 / 5
Behavioural Signals Velocity, value, anomaly score
3.4 / 5
Mitigations Applied EDD evidence + 4-eyes review
−2.3
Inherent risk4.1 / 5
Mitigation−2.3
Residual risk2.4 / 5
Final bandMEDIUM
DecisionPROCEED · review in 365d