suppliers

Create suppliers and their contacts in one call

Creates suppliers and answers 201 with each one as get_supplier_details serves it. The body is {"suppliers": [...]}; every entry needs a name, and may carry the address, currency, min_order_value, lead_time, payment_terms_days, domains, a contacts list and a primary_contact.

A supplier's id is derived from its name, so this call is idempotent on the name and never overwrites. Posting a name that already exists answers the supplier on file, unchanged, with none of the fields in the body applied, and 201 either way. update_supplier is the door for changing a supplier that exists. Two entries with the same name in one body are collapsed to the first.

contacts are created with the supplier and deduplicated on (email, name). A contact with no preferred_contact_method takes email when an email is given and phone otherwise, and in that same case a contact with an email and no name takes the local part of the address, state preferred_contact_method yourself and the name stays null. primary_contact names an existing contact by id and does not create one.

domains is what routes a supplier's mail: a domain like acme.example or a whole address like orders@acme.example. Anything that is neither is refused 400, because a bad entry matches nothing and nothing reports it.

Scope: suppliers:write, which includes suppliers:read.

post/api/v1/inventory/suppliers

Request

  • Base URL: https://api.app.tightly.io
  • URL: https://api.app.tightly.io/api/v1/inventory/suppliers
  • Auth: HTTP bearer

Headers

Tightly-Versionstring
Example:2026-11

The date train to answer on. One train exists today, 2026-11, the one this reference describes and the one every key is minted on, so the call answers on it with or without this header. Send it anyway, so a client built now names its train from the start.

Idempotency-Keystring
Example:b8f1c0d2-6a4e-4f39-9c21-0d5f2e7a1b44

A string of your own, up to 255 characters, that makes this write safe to retry. Send the same key twice and the second request is answered with the first one's status and body instead of writing again, so a client that retried after a timeout ends holding the record's id rather than creating a second one. Reusing a key with a different body, or while the first request is still running, is refused 409. A write that failed releases its key. Keys answer for 24 hours and belong to the API key that used them. A key longer than 255 characters is ignored and the write goes ahead without the guarantee.

Request body

Response

The suppliers as they now stand, the ones created, and unchanged for any name that already existed.

Changes

No recorded changes to this operation across all 1 revision of this API.