Skip to main content
Delivery

Setting up delivery and test-fire

A reviewed order still needs somewhere to go. Delivery is configured per supplier under Partners → Suppliers → Delivery — until it's set up, sending stops honestly at "delivery not set up" instead of pretending.

This article is the reference for the delivery settings. For the set-up in order, channel by channel, follow set up delivery to a supplier and test-fire it.

Pick the channel the supplier actually uses

  • HTTP webhook — the supplier exposes an endpoint; ProcuLink posts the order there. Auth options: none, API key, bearer token, basic, or OAuth2 fetch-token. Growth plan and up.
  • SFTP / FTPS — the order file is dropped on the supplier's server (password or private-key authentication). Every plan.
  • Email — the order goes out as an email attachment, sent over HTTPS from ProcuLink's mail servers (you don't run or configure an SMTP server). Every plan.
  • Erply / Directo — purpose-built ERP adapters for those tenants. They authenticate and deliver the generated order artifact into the ERP — the same output the other channels send, not a native re-modelling of the order inside the ERP. Enterprise plan and up.

Pick HTTP when the supplier publishes an API, SFTP/FTPS or email for file-based suppliers, or the ERP adapter when you share an Erply or Directo tenant — and check the plan note above before you promise a supplier a channel. Saving a delivery config on a channel your plan does not include is refused at the point of saving.

On the same tab you set the output format the supplier requires (CSV, XML, cXML, UBL 2.1, X12, JSON) — sending auto-transforms into it. All of these are on every plan except cXML, which is Operations plan and up.

Configuring HTTP delivery

Enter the webhook URL, the auth method (none, API key, bearer, basic, or OAuth2 fetch-token — which fetches a fresh access token from the supplier's token endpoint before each send), and any required headers. Credentials are encrypted at rest with AES-256-GCM.

Send a test before the first real order

After saving the config, use Send a test now (or the Test-fire button). ProcuLink sends a real test payload to the configured destination and shows you the verbatim result: success or failure, the error message if any, and the response code.

This is the rehearsal that makes the first real send boring — it proves credentials, the URL/host, and the network path against the supplier's actual endpoint.

A successful test is not an accepted order

Be precise about what a green test means: the supplier's endpoint answered — it doesn't mean an order was accepted. An HTTP 200 proves the connection works; it says nothing about whether the supplier's system will take a given order's content (their side can still reject unknown item codes, missing fields, or business rules). That's why ProcuLink tracks a separate supplier-response stage after delivery, and why a delivered order can still come back rejected_by_supplier.

What the statuses mean

ready_to_deliver → delivering → delivered on success. A failure lands in delivery_failed with the attempt's error captured for retry. A transform artifact alone does not mean the order was sent — the explicit delivered state is the source of truth. If the failure is "delivery config is missing", retrying won't help — set up delivery first.

Need help? Email support@proculink.eu or see Troubleshooting common parse errors.