Connect supplier information to your ecosystem.

Use SDS integration services to exchange authorized supplier information, reflect program and module requirements, and keep downstream business systems aligned with SupplierSync™.

API examples on this page are illustrative and should be aligned with the final production specification before publication.

supplier-profile.sh

# Illustrative example
curl --request GET \
  --url https://api.example.supplierds.com/v1/\
suppliers/sup_example/profile \
  --header "Authorization: Bearer $SDS_TOKEN" \
  --header "X-SDS-Workspace: ws_example"

# Response
{
  "supplier_id": "sup_example",
  "status": "active",
  "modules": [
    "contacts",
    "certifications",
    "compliance"
  ]
}

Endpoint paths, payloads, event names, credentials, and URLs on this page are illustrative until confirmed in the production SDS API reference and your integration agreement.

From access to first synchronized record.

A typical SDS integration begins with a scoped workspace, continues through supplier and module mapping, and moves to controlled event handling before production release.

1

Request access

Establish your technical contact, environment, use case, and permitted information scope.

2

Map your model

Align internal supplier identifiers, fields, modules, and ownership rules.

3

Build and test

Authenticate, read or submit test data, verify errors, and validate webhook handling.

4

Release safely

Complete acceptance checks, protect credentials, monitor events, and reconcile results.

ERP agnostic by design.

SDS complements transactional and procurement platforms. Your enterprise system remains the system of record for transactions, while SDS supports the collection, maintenance, and authorized exchange of supplier information.

Your enterprise systems

⇄

SDS integration layer

Buyer workspace & programs

⇄

Supplier-maintained profile

Request access and confirm environments

Begin with an approved integration use case. SDS will associate technical access with the appropriate organization, workspace, environment, permissions, and data scope.

Name an integration owner and security contact.
Define inbound, outbound, or bidirectional information flows.
Confirm the relevant supplier population and information modules.
Separate non-production and production credentials.

Do not place credentials in client-side code. Store secrets in an approved server-side secret manager and rotate them according to your security practices and SDS requirements.

Authenticate server-to-server requests

Use the authentication method assigned to your integration. The conceptual example below shows a short-lived bearer token flow.

Illustrative token request

curl --request POST \
  --url https://auth.example.supplierds.com/oauth/token \
  --header "Content-Type: application/x-www-form-urlencoded" \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "client_id=$SDS_CLIENT_ID" \
  --data-urlencode "client_secret=$SDS_CLIENT_SECRET" \
  --data-urlencode "scope=suppliers:read modules:read"

Select the buyer workspace and program

Workspace and program context determine which suppliers, modules, permissions, and requirements apply. Never assume that access in one workspace carries into another.

Illustrative workspace lookup

GET /v1/workspaces
Authorization: Bearer <token>

{
  "data": [{
    "workspace_id": "ws_example",
    "name": "Example Buyer Workspace",
    "programs": ["prg_supplier_information"]
  }]
}

Resolve the SDS supplier identity

Maintain a durable cross-reference between your internal supplier identifier and the SDS supplier identifier. Use matching and review workflows rather than creating duplicates when identity is uncertain.

Illustrative supplier resolution

GET /v1/suppliers?external_id=VENDOR-10482
Authorization: Bearer <token>
X-SDS-Workspace: ws_example

{
  "data": [{
    "supplier_id": "sup_example",
    "external_ids": [{"system":"erp","value":"VENDOR-10482"}],
    "match_status": "confirmed"
  }]
}

Identity is foundational. A supplier match should be confirmed before module data is synchronized or a new profile is created.

Read or submit authorized module data

Modules organize supplier information by business purpose. Confirm entitlement, schema version, field ownership, validation rules, and direction of synchronization before processing a module.

Illustrative certification record

GET /v1/suppliers/sup_example/modules/certifications
Authorization: Bearer <token>
X-SDS-Workspace: ws_example

{
  "module": "certifications",
  "schema_version": "example-1",
  "records": [{
    "type": "example_certification",
    "status": "current",
    "valid_to": "2027-06-30",
    "updated_at": "2026-08-10T18:42:00Z"
  }]
}

Preserve timestamps and source metadata when available. Treat validation errors as actionable data-quality results rather than silently dropping fields.

Subscribe to change events

Webhooks can reduce polling and notify your integration when relevant supplier or module information changes. Verify signatures, acknowledge quickly, and process asynchronously.

Illustrative webhook event

{
  "event_id": "evt_example",
  "event_type": "supplier.module.updated",
  "occurred_at": "2026-08-10T18:42:00Z",
  "workspace_id": "ws_example",
  "supplier_id": "sup_example",
  "module": "certifications",
  "schema_version": "example-1"
}

Verify the event signature before processing.
Use the event ID for idempotency and duplicate protection.
Return the required success response promptly.
Fetch the authoritative record when the event is a change notification.

Complete production readiness

Move to production only after functional, security, privacy, reconciliation, and operational acceptance checks are complete.

Design for recovery. Your integration should be able to replay safely, reconcile counts and timestamps, isolate failed records, and resume without creating duplicates.

Map only what your program requires.

Module availability, schemas, field requirements, and access depend on the customer bundle, program configuration, participant relationship, and technical release.

Before production