Connectors / Integration planning

StellaOS + your procurement stack

We build AI-native procurement software around the systems your team already relies on. Plan the connections across ITSM, CLM and ERP—without giving up human control.

ITSMCLMERP

An honest starting point

The StellaOS demo includes simulated ITSM, CLM and ERP adapters. It does not connect to your live systems. Production-ready connectors, StellaOS API contracts and vendor-certified integrations are not established by this demo.

The steps below cover real vendor-side setup and the implementation work to scope with the StellaOS team. Your system administrators must confirm API availability, permissions and release-specific requirements before connecting production data.

01 / Connection guides

From access to a tested handoff

ITSM platform

Connect the request, not another inbox.

Plan a handoff between service requests and procurement intake, with a shared reference so teams can trace the same request in both systems.

Service request → Procurement intake → Status reconciliation

Proposed mapping to agree

Request number · requester · description · business justification · procurement reference · status

  1. 01

    Choose the request record

    Have your ITSM administrator identify the source record and fields. Decide which requests should reach procurement and which system owns each status. Do not assume every request type uses the same record structure.

  2. 02

    Set up restricted API access

    In a non-production instance, configure an integration identity and an administrator-approved authentication method. Grant only the record and field access the flow needs; your platform's access controls still govern API access. Keep credentials in a secret store, never in a browser.

  3. 03

    Implement the handoff

    Use your platform's REST API to read an agreed test record. Map its fields into a StellaOS intake contract agreed with the StellaOS team, then implement the receiving adapter. Store the source record ID and procurement reference together. No public StellaOS intake endpoint is documented on this site.

  4. 04

    Test both directions

    Test a complete request, missing details, denied access and a repeated delivery. Verify that a duplicate does not create a second intake. If status write-back is in scope, restrict it to agreed fields and reconcile the result in both systems.

Vendor-side starting point · not a StellaOS endpoint

GET {your-ITSM-REST-base}/{requestRecord}

Your ITSM platform's own REST API documentation is the source of truth. Ask your administrator for the reference that matches your edition and release.

02 / Shared controls

Agree the boundary before the connection.

  • One owner for each record

    Agree the source of truth for supplier, contract, request and requisition data. Keep cross-system IDs for reconciliation.

  • People keep approval authority

    Define which roles approve in each system. A sync, AI recommendation or successful API call must never stand in for a human decision.

  • Failures stay visible

    Define duplicate detection, safe retry rules, an error queue and an accountable owner. Reconcile unknown outcomes before resending a write.

  • A bounded production rollout

    Start in test environments with sample data. Review security, sign off the mapping and pilot a limited scope before widening access.

StellaOS intake-to-PO pipeline in the live demo environment
StellaOS demo pipeline · sample data, simulated adapters.

03 / Preparation

Bring a concrete integration brief.

For a scoping discussion, gather your system editions and releases, process owners, field dictionary, approval boundaries and a sample request lifecycle. Use anonymized examples—not production credentials or confidential contracts.

Jump straight into the live demo in one click, no sign-up.