Oracle SDS Integration Pattern

What this page is. An integration pattern, not a product. We do not ship or claim a certified connector for this platform; the API is a REST service that takes a multipart PDF upload, so any integration layer that can send multipart requests and read JSON can use it.

Land the JSON, then shape it with SQL

Oracle can store JSON in a column and query it with SQL, so the simplest pattern is to keep the whole outputs.json object per document and read it with JSON_VALUE and JSON_TABLE. Illustrative DDL and queries; adapt the types and JSON column to your Oracle version:

CREATE TABLE sds_extraction (
  request_id   VARCHAR2(64) PRIMARY KEY,
  received_at  TIMESTAMP DEFAULT SYSTIMESTAMP,
  confidence   NUMBER(4,3),
  status       VARCHAR2(20) DEFAULT 'staged',
  payload      CLOB CHECK (payload IS JSON)   -- the outputs.json object
);

-- one value
SELECT request_id,
       JSON_VALUE(payload, '$.transport_information.un_number') AS un_number
  FROM sds_extraction;

-- one row per substance
SELECT e.request_id, jt.substance, jt.cas, jt.concentration
  FROM sds_extraction e,
       JSON_TABLE(e.payload, '$.composition[*]'
         COLUMNS (substance      VARCHAR2(200) PATH '$.substance_name',
                  cas            VARCHAR2(20)  PATH '$.cas_number',
                  concentration  VARCHAR2(40)  PATH '$.concentration_percent')) jt;

The sub-field names here come from our sample response. The contract guarantees the 16 section keys, not the fields inside them, so check what your own documents return and expect some paths to be null.

Staging first, promotion second

1. Your integration layer calls the API and inserts the JSON into sds_extraction with status = 'staged'.
2. A reviewer, or a rule on confidence and the warnings in the payload, moves clean records to approved.
3. A job copies approved records into your product and substance tables, matching substances on CAS number.
4. Rejected or flagged records stay in staging with the reviewer's note.

Calling the API

• The API takes a multipart/form-data upload and returns JSON. Use middleware or a small service that can build the multipart request, and write the result to the database.
• Keep the API key in a secret store, not in PL/SQL or a client.
• Use an Idempotency-Key on bulk submissions so a retry does not create a second job.
• Webhooks need a public HTTPS callback_url. If your database tier is not internet-reachable, poll the job status endpoint.

Details worth getting right

• Concentrations are strings. 95-100 is a range, so convert it in a controlled step.
• Key on request_id. It is the trace back to the extraction, and a natural primary key for staging.
• Keep the raw payload. Even after you promote values into relational columns, the original JSON is what a reviewer needs.

How you get access: the free sample upload on the homepage needs no key, the self-serve plan issues an API key after signup, and enterprise customers get a dedicated deployment with its own base URL. See pricing.

FAQ

Related pages

• SAP SDS integration pattern
• Salesforce SDS workflow pattern
• SDS field coverage matrix
• OpenAPI contract