SAP 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.

The shape of the integration

SDS PDF in (supplier e-mail, portal, document store)
   -> integration layer      : builds the multipart request, holds the API key
   -> SafetyDataSheetAPI     : POST /extract-sds  (or /extract-sds/bulk)
   <- JSON                   : outputs.json + confidence_score + warnings + request_id
   -> staging table          : raw JSON, request_id, confidence, status = "staged"
   -> review                 : people check flagged documents
   -> write to SAP EHS data  : approved records only, matched on CAS / product key

The important choice is the staging step. Extraction is machine-generated, so write results to a staging area first and let only approved records reach SAP EHS or product compliance data.

Where each part of the response typically goes

Names differ by SAP product and by how your system is configured, so read these as concepts to map, not table names.

Practical points for SAP teams

• Match substances on CAS (and EC) numbers, not on names. Names vary by supplier and language.
• Concentrations are text. A value such as 95-100 is a range string. Parse it deliberately before it reaches a numeric field.
• Multipart is a requirement of the API, so the layer that calls it must be able to build a multipart/form-data request. Many SAP-adjacent integration layers can; if yours cannot, put a small service in front.
• Behind a firewall? Poll instead of using webhooks. A webhook callback_url must be a public HTTPS address. If your SAP system cannot be reached from the internet, submit a bulk job and poll GET /extract-sds/bulk/{jobId}.
• Keep the API key in your integration layer's secret store, never in ABAP code or a client.
• Store the request_id with every staged record so a reviewer can trace it back.

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.

Checklist before you go live

1. Run a sample of your own SDS through the API and map the sections you need.
2. Decide the confidence threshold and warning policy that sends a document to review.
3. Build the staging table and the approval step before the write step.
4. Test the duplicate case: resubmit with the same Idempotency-Key and confirm nothing is created twice.
5. Agree who owns review, and how quickly flagged documents must be handled.

FAQ

Related pages

• EHS platform SDS ingestion
• Oracle SDS integration pattern
• Salesforce SDS workflow pattern
• OpenAPI contract