Connect your systems
Connect a system
Credentials, endpoints and the first handshake, and the checks that stop a connection failing in week three instead of on day one.
Connecting an ERP, PIM, CRM or warehouse system is mostly preparation. The handshake itself takes minutes; what takes time is deciding what crosses the line and getting credentials that will still work in a year.
Before you begin. Settle
which system owns which field and
which pattern each flow uses.
You also need, from whoever runs the other system: an endpoint, a technical
account, and a named person who will answer when something breaks at 03:00.
Gather what you need
Ask for these in one message rather than four:
| What | Why it matters |
|---|---|
| Endpoint URL, per environment | Test and production are different systems. Never connect production first |
| Protocol and format | REST/JSON, SOAP with a WSDL, SFTP with CSV or BMEcat, or a database view |
| Credentials | A technical account, not a personal one. Personal accounts leave the company |
| Authentication method | API key, OAuth client credentials, basic auth, or an SSH key for SFTP |
| Rate limits and maintenance windows | So your nightly run does not collide with their backup |
| A sample payload with real data | Ten real articles, not a clean example. Real data is where the surprises are |
| Contact and escalation path | The person, not the ticket queue |
Connect it
- Check Extend and Develop › Marketplace first. If a prepared connector exists for the system, install it; it brings its own screens and its own credential form, and workflows use it as a node instead of you assembling raw HTTP calls. Installed ones are listed under Extend and Develop › Installed Integrations.
- Go to Integrations › Credentials and select New credential.
- Enter the endpoint for your test environment, and name the credential
for the system and the environment —
erp-test,erp-prod. You will read these names in run logs. - Enter the authentication details. Anything you do not want visible in a workflow definition (a password, a shared secret, a private key) belongs in Integrations › Secrets and is referenced from the credential. Keeping credentials and secrets out of the workflow is what lets the same workflow run against the test ERP and then against production without being edited.
- Set the timeout and retry behaviour. For a batch feed, generous timeouts and several retries. For a live call that a page waits on, a short timeout and a fallback; a page that hangs for 30 seconds is worse than a page that shows a cached figure.
- Run the connection test. It authenticates and reads, and changes nothing.
- Save.
What to check
A green test only proves the credentials work. Before you build anything on top:
- Pull ten real records and read them. Read the values rather than the count.
Look at the unit of measure, the decimal separator, the date format and the encoding.
Umlauts arriving as
Ma�mean an encoding mismatch that will otherwise be discovered by a customer. - Check the customer number and SKU formats. Leading zeros are the classic:
the ERP has
0004711, the shop has4711, and nothing matches. Decide now which form is canonical. - Confirm the account's permissions are read-only where they should be. A technical account that can write to the ERP by accident is a bad afternoon.
- Ask what happens when their system is in maintenance. A clean error is workable. A login page returned with HTTP 200 is not, and you want to know before your parser tries to read it as product data.
Then move to production
Create a separate credential for production. Do not edit the test one to point at production. You will want the test one again, and mixing them means a test run can write to live data. Because workflows reference credentials by name rather than embedding them, switching a workflow from test to production is a change of one field.
Run the first production job with a small, restricted scope: one product group, one customer, one day. Compare the result by hand against the source. Only then widen it.
Never point a test environment at production write endpoints. A test run that
transmits 400 orders into a live ERP is a real incident, it happens more often
than anyone reports, and it is entirely preventable by keeping the two
connections separate from the start.
When it does not work
| Symptom | Usual cause |
|---|---|
| 401 / 403 on a connection that worked yesterday | Password rotated, or the technical account expired |
| Connection times out from here but works from their office | Your outbound addresses are not on their firewall allow-list |
| TLS or certificate error | An expired certificate on their side, or an internal CA your side does not trust |
| Test succeeds, first real run returns nothing | The account authenticates but has no read permission on the data |
| Everything works, values look wrong | Encoding or locale: check decimal separators and date formats first |
Next
- Field mapping: turn their field names into yours.
- Build a workflow: put the connection to work on a schedule.