Non-Inventory Items

Overview

The Non-Inventory Items API lets your system push GL-based catalogue products to SoftCo's AP and procurement platform. Non-inventory items give organisations a way to structure their general ledger accounts as purchasable items — without needing a traditional item master. Instead of creating inventory records, you define which GL accounts should be available as selectable products in SoftCo's eRequisition (eReq) module, allowing AP users and budget holders to raise requisitions by picking from a controlled catalogue.

This approach is ideal for services, subscriptions, utilities, professional fees, and other non-physical spend categories where a full inventory item would be unnecessary overhead. Each non-inventory item maps directly to a GL account code — the code field is the GL account identifier — and SoftCo uses the associated metadata to populate the eReq catalogue, assign tax codes, and apply the correct coding when invoices are processed.

How non-inventory items relate to GL Account Codes

The field structure for this endpoint is identical to the GL Account Codes API. The difference is purpose and routing: while the GL Codes endpoint manages the full chart of accounts in SoftCo's AP platform, the Non-Inventory Items endpoint is specifically for the subset of GL codes you want to expose as purchasable catalogue entries. A code sent to this endpoint will appear in the eReq catalogue; a code sent only to GL Codes will be available for invoice coding but not self-service requisitioning.

Key catalogue features

Organisation scope and the organization field

Like all SoftCo master data, non-inventory items are scoped using the organization field. Use "organization": "main" for catalogue items available across the whole organisation. Supply a specific org code for items restricted to a particular legal entity. The behaviour is consistent with the GL Codes API and all other master data interfaces.

When to call this endpoint

Quick Start

Here's the fastest path to a successful integration. Copy this request, swap in your credentials and a real GL account from your ERP, then send it. The minimum required fields are organization, code, type, and description_en.

POST /non-inventory-items/v1
x-api-key:     your-api-key-here
Content-Type:  application/Json
Client_Id:     your-client-id
Client_Secret: your-client-secret

{
  "objects": {
    "object": {
      "record": [
        {      
        "organization":   "main",
        "code":           "6100",
        "type":           "DEDUCTABLE",
        "description_en": "IT Services"
        }
      ]
    }
  }
}

A successful response looks like this:

{
  "status":    "SUCCESS",
  "total":     1,
  "succeeded": 1,
  "failed":    0,
  "errors":    [],
  "message":   "All items processed successfully"
}

How It Works

Every request follows the same pipeline. Your system only needs to send once — resilience, retries, and delivery to SoftCo are handled automatically.

Authentication

All requests require an API key and OAuth 2.0 credentials. Your credentials are provided during onboarding — keep them secure and never expose them in client-side code or version control.

Requests with a missing or invalid API key are rejected by the gateway immediately and never reach the integration layer.

Required Headers

Response Codes

POST /non-inventory-items/v1

Submit one or more non-inventory item records to SoftCo. Each record maps to a GL account that will be available for AP coding and, where configured, published as a purchasable item in the eReq catalogue. The payload is validated, transformed to GL Codes XML, and queued for delivery.

Request Headers

Request Body

Your JSON payload wraps non-inventory item fields inside an objects → object → record envelope. This structure is consistent across all SoftCo master data endpoints.

A single request can carry one record or a batch of multiple records. For a single record request, record is a JSON array with only one element containing the field values. For a batch, record becomes a JSON array where each element is an object representing one item. The outer objects → object envelope remains the same in both cases.

Single record

Multiple records (batch)

Field Reference

All fields sit inside objects.object.record. The field set is identical to the GL Account Codes API — the difference is that fields like catalog_product and product_group are particularly significant here, as they control eReq catalogue behaviour.

Example Request

The examples below cover the most common scenarios. Replace field values with real data from your ERP.

Full Example — Catalogue-Published Item

A fully configured item published to the eReq catalogue, assigned to a product group, with a default tax code and locale descriptions.

POST /non-inventory-items/v1
Content-Type:  application/Json
x-api-key:     your-api-key-here
Client_Id:     your-client-id
Client_Secret: your-client-secret

{
  "objects": {
    "object": {
      "record": [
        {      
        "organization":      "main",
        "code":              "6100",
        "type":              "DEDUCTABLE",
        "description_en":    "IT Services",
        "description_en_US": "IT Services",
        "description_fi_FI": "IT-palvelut",
        "description_sv_SE": "IT-tjänster",
        "catalog_product":   "YES",
        "product_group":     "IT_SERVICES",
        "tax_code":          "S20",
        "start_date":        "2020-01-01",
        "end_date":          "2999-12-31"
        }
      ]
    }
  }
}

Minimum Required Fields

Only the four required fields. Catalogue settings and other fields can be added incrementally.

{
  "objects": {
    "object": {
      "record": [
        {      
        "organization":   "main",
        "code":           "6200",
        "type":           "DEDUCTABLE",
        "description_en": "Professional Consulting Fees"
        }
      ]
    }
  }
}

Batch — Multiple Items in One Request

When sending more than one item, record becomes a JSON array. Each element follows the same structure as a single-record request. The outer objects → object envelope stays exactly the same.

POST /non-inventory-items/v1
Content-Type:  application/Json
x-api-key:     your-api-key-here
Client_Id:     your-client-id
Client_Secret: your-client-secret

{
  "objects": {
    "object": {
      "record": [              // record is an array when sending multiple items
        {
          "organization":   "main",
          "code":           "6100",
          "type":           "DEDUCTABLE",
          "description_en": "IT Services",
          "catalog_product":"YES",
          "product_group":  "IT_SERVICES",
          "tax_code":       "S20",
          "start_date":     "2020-01-01",
          "end_date":       "2999-12-31"
        },
        {
          "organization":   "main",
          "code":           "6200",
          "type":           "DEDUCTABLE",
          "description_en": "Professional Consulting Fees",
          "catalog_product":"YES",
          "product_group":  "PROFESSIONAL_FEES",
          "tax_code":       "S20",
          "start_date":     "2020-01-01",
          "end_date":       "2999-12-31"
        },
        {
          "organization":   "main",
          "code":           "6300",
          "type":           "DEDUCTABLE",
          "description_en": "Office Supplies",
          "catalog_product":"YES",
          "product_group":  "OFFICE_SUPPLIES",
          "tax_code":       "S20",
          "start_date":     "2020-01-01",
          "end_date":       "2999-12-31"
        }
      ]
    }
  }
}

Validation

Your payload is validated before anything else happens. If validation fails, you get a 400 immediately — nothing is queued or forwarded. Fix the payload and retry.

What gets checked

Troubleshooting

The most common issue is a 400 Bad Request. The response body always includes an error_message field that tells you exactly what went wrong.

Item not appearing in the eReq catalogue?

If you received a 202 Accepted but the item has not appeared in the SoftCo eReq catalogue after several minutes, first check that catalog_product was set to YES in your payload — items sent with NO or without this field will not be published to the catalogue. If the field was set correctly, there is no need to take immediate action — the integration queue manages retries automatically. Contact your SoftCo Customer Success representative with the approximate timestamp of your request if the issue persists. Resending the record is safe — SoftCo processes all master data as incremental updates.

Item appears in AP but not in the eReq catalogue?

This can occur if catalog_product was set to NO (or omitted) in a previous request. Resend the record with catalog_product set to YES and the correct product_group to publish it to the catalogue.

Example Responses

202 Accepted — All Records Processed

Every record in the request was validated and queued successfully. Delivery to SoftCo is asynchronous and typically completes within minutes.

{
  "status":    "SUCCESS",
  "total":     1,
  "succeeded": 1,
  "failed":    0,
  "errors":    [],
  "message":   "All items processed successfully"
}

207 Multi-Status — Partial Success

Some records were queued; one or more failed validation. Only the failed records need to be fixed and resubmitted.

{
  "status":    "PARTIAL",
  "total":     2,
  "succeeded": 1,
  "failed":    1,
  "errors":    [
    {
      "index": 2,
      "error": "description_en is required."
    }
  ],
  "message":   "Your request was partially successful. 1 of 2 records were queued for delivery."
}

400 Bad Request — Invalid Request Structure

The request envelope is missing or malformed. No records were processed.

{
  "status":           "FAILED",
  "total":            0,
  "succeeded":        0,
  "failed":           0,
  "errors":           [
    {
      "index": 0,
      "error": "The request is missing the objects section."
    }
  ],
  "message":          "No items could be processed as the request structure was invalid.",
  "expected_format":  "objects → object → record (record must be a non-empty array of items)"
}

401 Unauthorized

API key missing or invalid. Request rejected at the gateway.

{
  "status":    "FAILED",
  "message":   "Unauthorized — API key is missing or invalid"
}

What's Next

Non-Inventory Items is the final master data interface. With all four master data APIs in place, SoftCo has the complete reference data set it needs — you're ready to start sending transactional data.

Master Data — Complete

All four master data interfaces are now documented. Each one builds on the same queue-based architecture and consistent payload structure.

Transaction Data — Up Next

With master data in place, these three interfaces enable the day-to-day AP processing workflows in SoftCo. Start with Purchase Orders, then Goods Received, and finally Payment Confirmations to complete the end-to-end AP cycle.