Connect Sage 100 / Sage 300: verify Sage 300 Web API connectivity

One connection covers both products and the variant field decides which one you mean: sage300 runs a real connectivity test against the Sage 300 Web API with your service address, company code and user account, while sage100 returns an honest not-available result. Fill in variant, base URL, company, username and password, then test — Sage 300 first.

This is one connection for two Sage products, and the first field, variant, decides everything that follows. With variant set to sage300, the connection verifies that this system can reach your Sage 300 Web API: it signs in with your Sage 300 user account over HTTP Basic and reads your company profile once. With variant set to sage100, the test does not send any request at all — it returns an honest not-available result, because the Sage 100 eBusiness Web Services call is SOAP-based and its request has to be confirmed against your own WSDL first. For both products, keep the scope in mind: this connection verifies connectivity only. It does not pull orders, customers or inventory in, and it does not push inventory back — for Sage 300, the field names its views return have to be confirmed against the swagger of your own deployment first. A passed Sage 300 test proves the five values below work together for that company, and nothing more.

Prerequisites#

• You know which product you actually run: Sage 300 or Sage 100. This decides the variant value, and the two paths behave completely differently in the test.
• For Sage 300: the Sage 300 Web API service is running on your server, at an address in the form https://server/Sage300WebApi. You can check the service yourself by opening {baseUrl}/swagger in a browser — if that page answers, the service is up.
• A user account in your local Sage system for the integration: for Sage 300, a Sage 300 user that can sign in over HTTP Basic and is allowed to use the Web API; for Sage 100, a Web Services user. There is no cloud sign-up for these credentials — the account lives in your own Sage system.
• Your company code: for Sage 300, the company Org ID that appears in the Web API address, for example SAMINC; for Sage 100, your company code.

Get your credentials#

1. Decide the variant word first, before collecting anything else: type sage300 if you run Sage 300, or sage100 if you run Sage 100. The exact word matters — the test reads it literally.
2. For Sage 300, note the Web API address of your server, for example https://server/Sage300WebApi. Open {that address}/swagger in a browser first: if the page answers, you have the right address and the service is running.
3. For Sage 100, note the eBusiness Web Services address of your server instead, for example https://server/ebusinesswebservices. Keep it ready together with your WSDL, which your Sage administrator holds.
4. Note your company code: for Sage 300, the company Org ID used in the Web API address, for example SAMINC; for Sage 100, the company code of the company you want to connect.
5. Ask your Sage administrator for the integration user account in your local Sage system, and note its username and password as a pair: for Sage 300, the Sage 300 user for HTTP Basic sign-in; for Sage 100, the Web Services user. Use an account made for the integration, not a person’s everyday sign-in.

Fill it into Integration#

1. Open Integration → Connector Marketplace → Sage 100 / Sage 300 → New connection.
2. variant — required, Product variant: type the single word sage300 if you run Sage 300, or sage100 if you run Sage 100. sage300 goes to the Sage 300 Web API (OData). sage100 goes to the Sage 100 eBusiness Web Services (SOAP), which needs your WSDL confirmed first and is not open for testing yet.
3. base_url — required, Service base URL: for Sage 300, paste your Web API address, for example https://server/Sage300WebApi. For Sage 100, paste your eBusiness Web Services address instead, for example https://server/ebusinesswebservices.
4. company — required, Company code: for Sage 300, type the company Org ID that belongs in the Web API address, for example SAMINC. For Sage 100, type your company code.
5. username — required, Username: type the username of the integration account in your local Sage system — the Sage 300 user for sage300, the Web Services user for sage100. The example form is an API username created for this connection.
6. password — required, Password: paste the password of that same account. It is a password-type field and stored as a secret. The username and the password must belong to the same account.

Test the connection#

Click Test connection. What happens depends on variant, and the test reads that field first. If variant is empty, the test stops with MISSING_VARIANT; if it is neither sage300 nor sage100, it stops with INVALID_VARIANT. If variant is sage100, the test returns the ERP_ENDPOINTS_PENDING result right away and sends no request at all — that is the honest answer for Sage 100 today, not an error in your other fields. If variant is sage300, the test checks the other four fields and stops with MISSING_BASE_URL, MISSING_COMPANY, MISSING_USERNAME or MISSING_PASSWORD if one is missing. It then signs in with HTTP Basic — your username and password — and reads the company profile, the lightest metadata it can ask for, at {base}/v1.0/-/{company}/CS/CSCompanyProfile with a 12-second limit. An answer of 200 passes. A 401 is reported as INVALID_TOKEN, a 403 as MISSING_SCOPE, and a 404 as NOT_FOUND — see the FAQ for what each one means.

Mapping / pick a template#

There is no standard mapping and no template to pick for this connection. For Sage 300, the views return field names that follow the swagger of each deployment, so any order, inventory or customer mapping has to be confirmed against {baseUrl}/swagger of your own server when a data connection is set up for you — it is not something to guess or to fill in here. For Sage 100, the SOAP request itself first has to be confirmed against your WSDL. Until that per-deployment confirmation exists, this connection stays at the connectivity check it performs in the test step. Do not rename views or fields in Sage to match a guessed mapping.

Activate#

For Sage 300, after the test passes, activate the connection to save it in Integration with these verified values, so the same company can be checked again later with the same account. Activation does not start any data flow: no orders, customers or inventory move through this connection, in either direction. If the password of the integration account changes later, update the password field here and test again. For Sage 100, there is nothing to activate yet — the test result already told you the state, and changing the other fields will not change it.

FAQ#

I use Sage 100 and the test returns ERP_ENDPOINTS_PENDING

That result is expected for Sage 100, and it is not caused by anything you typed. The moment the test reads variant as sage100, it returns this result without sending any request, because the Sage 100 connection goes through eBusiness Web Services over SOAP, and that request has to be confirmed against the WSDL of your own deployment first. No address, company code, username or password can change this outcome today.

Do not keep changing the other fields — they are not the cause. Check only one thing: if you actually run Sage 300, change variant to sage300 and test again, because you were on the wrong path. If you truly run Sage 100, keep your service address, company code and Web Services user ready together with your WSDL, and wait for the Sage 100 path to open before completing this connection.

Test stops with MISSING_VARIANT or INVALID_VARIANT

The test reads variant before anything else, because that one word routes the whole test. MISSING_VARIANT means the field is empty. INVALID_VARIANT means the word in it is neither of the two words the connection accepts — a product name written in another form, with extra words, or with a space, routes nowhere.

Type exactly one word in variant: sage300 for Sage 300, sage100 for Sage 100 — no spaces, no extra words. Save, then test again.

Sage 300 test fails with INVALID_TOKEN (401)

The Sage 300 Web API did not accept the HTTP Basic sign-in — your username and password, as a pair, were refused. The usual causes are a typing or copying error, a password that has changed since you noted it, or a username paired with the password of a different account.

Re-copy the username and password of the one integration account from your Sage administrator, with no extra spaces, confirm the username is in username and the password in password, and test again. If the account password was reset in Sage, use the new one here.

Sage 300 test fails with MISSING_SCOPE (403)

The sign-in worked, but that Sage 300 user is not allowed to use the Web API. The address and the company were reached — the account itself is missing the Web API permission, so changing the address or the company code will not fix this one.

Ask your Sage administrator to allow that user to use the Sage 300 Web API, or to give you another Sage 300 user that already has the permission. Update username and password here if the account changes, then test again.

Sage 300 test fails with NOT_FOUND (404)

The company profile the test asks for was not found at that address for that company. Either the company code does not match the Org ID of a company on that server, or the base_url does not point at the Sage 300 Web API root — a small difference in the address has the same effect.

First open {baseUrl}/swagger in a browser: if it does not answer, fix base_url until it does, and check that the address ends at the Web API root, for example https://server/Sage300WebApi. If swagger answers, check company against the Org ID used in your Web API addresses, for example SAMINC, then test again.

Sage 300 test stops with MISSING_BASE_URL, MISSING_COMPANY, MISSING_USERNAME or MISSING_PASSWORD

On the sage300 path, the result names the exact field that is empty. The test checks these four fields after variant and sends nothing until all of them are present, because the company profile read needs the address, the company and the Basic sign-in together.

Fill in the named field — service base URL, company code, username or password — from the values you collected, save, and test again. Repeat until no missing result appears.

The Sage 300 test passed, but no orders, inventory or customers are synced

That is the current scope of this connection, not a fault in your values. The test only proves that the Basic sign-in and the company profile read work. Data movement is not part of this connection yet, because the field names the Sage 300 views return follow the swagger of each deployment and first have to be confirmed against {baseUrl}/swagger of your own server.

Treat a passed Sage 300 test as a verified connection for this company, and keep order, inventory and customer work in Sage 300 itself for now. When a data connection is set up for your deployment, it will start from these same verified values and from your swagger — you will not need to collect the credentials again.