SmartConnect

SmartConnect is an integration platform as a service from eOne Solutions, a company founded in Sydney in 2001 as a Microsoft Dynamics GP implementation firm and now headquartered in Fargo, North Dakota, with offices in Austin, Sydney and Copenhagen. eOne states it serves around 6,000 companies across 47 countries through more than 350 partners, and in 2025 it acquired DataBlend, a finance-focused integration platform.

The vendor identification matters, because the name is heavily overloaded. This entry is eOne Solutions SmartConnect, reachable at smartconnect.com, which redirects to eonesolutions.com/app/smartconnect/. It is not an Indian retail product, and the unrelated smartconnect.in domain serves a personalised email and URL page with no connection to it. Lenovo, Motorola and Microsoft also ship consumer device features called Smart Connect. None of those is this.

The second thing to be clear about: SmartConnect is not a system of record. It holds no orders, no listings, no inventory and no customers of its own. It is the pipe. For our purposes it is a connector to a connector: if a brand already runs SmartConnect between, say, Business Central and Shopify, its API lets us trigger those integrations, read what they moved, and read what failed.

At a glance

What it is

eOne describes SmartConnect as letting you "connect, move, and share information across your entire ERP ecosystem, without sweating the format". The published connector set covers Microsoft Dynamics GP, NAV, Business Central and Dynamics 365, Salesforce, Oracle NetSuite, Shopify, HubSpot, Zendesk, REST and SOAP web services, SQL, ODBC, Excel and flat files. Both cloud and on-premise deployments exist, which is visible in the API through a metadata endpoint that lists SmartConnect deployment types.

Integrations are built in a drag-and-drop mapper with pre-built connectors and templates, transformations, calculations, date functions and scripting. Automation triggers are scheduled, event-based or change-only. There is an Excel add-in, error handling with email alerts, and the REST API documented here.

The core objects in the product, which are also the objects in the API:

• Connection. A configured link to a system, for example a Business Central tenant or a Shopify store.
• Data source. A query or extract against a connection.
• Integration process. A mapping from one or more sources to a target, with transformations.
• Integration group. A collection of processes run together.
• Schedule. When a process or group runs.
• Run. One execution, with a run number, record count, error count and error rows.
• Translation table. A lookup used during mapping, for example channel code to ERP customer code.
• Event log and process errors. Monitoring and the failed-record queue.

API access

Access is self-service inside the product, which is unusual for this catalogue and welcome.

From eOne's own instructions in the Postman collection:

1. Sign in to your SmartConnect tenant at login.smartconnect.com.
2. Go to System, then API Settings.
3. At the bottom of the screen click Add Registration.
4. Give the application a friendly name.
5. Set the type to Web API.
6. Click Activate.
7. Copy the Client Id, the Client Secret and the API REST Service Url.

That third value matters: the REST service URL is per tenant. The Postman collection's default baseUrl is https://smartconnect-eone-api.azurewebsites.net, which is where the public Swagger is hosted, but a customer's own base URL comes from their API Settings screen. Do not hard-code the Azure host.

There is one API version, v1, expressed as a path prefix. No deprecation policy is published. Support is at support@smartconnect.com.

For an on-premise SmartConnect deployment, whether the same REST API is available is not stated in the specification, and the presence of a deployment-type metadata endpoint suggests the two differ. Confirm with the customer which they run.

Authentication

OAuth 2, password grant. The Swagger specification declares a single security definition: oauth2, flow password, token URL /token, with no scopes.

Get a token:

POST /token HTTP/1.1
Host: your-tenant-api-host
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=USER_EMAIL&password=USER_PASSWORD&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

The vendor documents the five body parameters as: grant_type set to password, username as the SmartConnect user email address, password as that user's password, and client_id and client_secret from the application registration.

The response carries access_token, token_type, expires_in and a refresh token.

Refresh:

POST /token HTTP/1.1
Host: your-tenant-api-host
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token&refresh_token=REFRESH_TOKEN&client_id=CLIENT_ID&client_secret=CLIENT_SECRET

Authenticated call:

GET /v1/integration?page=1&pageSize=100 HTTP/1.1
Host: your-tenant-api-host
Authorization: Bearer ACCESS_TOKEN
Accept: application/json

Notes for the credential store:

• Four secrets, not two. A password grant means you are storing an actual user's password alongside the client credentials. Create a dedicated service user in the customer's tenant rather than using a person's login, and agree with the customer who owns its password rotation.
• expires_in is returned, so drive refresh from it rather than from a fixed interval, and re-authenticate from scratch if the refresh token is rejected.
• The API is scoped to the signed-in user. The connection list endpoint is documented as returning "the list of connections available to the signed in user", so what you can see depends on that user's rights inside SmartConnect. Check the service user's permissions before concluding that a connection is missing.
• Tenancy is the credential. One tenant equals one set of credentials and one base URL.

Objects we can read

No commerce object is readable directly. What follows maps the API's own objects, and then shows the two endpoints that reach through to real data.

Integrations

• GET /v1/integration/{id} returns one process.
• POST /v1/integration/search filters the list. All filters are optional: SourceProductType, SourceType, TargetProductType, SearchString, CreatedFrom, CreatedTo, LastRunFrom and LastRunTo. Valid type values come from the metadata endpoints.

[
  {
    "Key": "<uuid>",
    "Id": "<string>",
    "Description": "<string>",
    "SourceSystem": "<string>",
    "TargetSystem": "<string>",
    "CreatedDate": "<dateTime>",
    "LastRunDate": "<dateTime>"
  }
]

• GET /v1/integration/{id}/columns lists the columns of a process, with an allColumns switch.
• GET /v1/integration/{id}/history returns run history.
• GET /v1/integration/{id}/output returns file outputs.
• GET /v1/integration/gp and GET /v1/integration/groups are Dynamics GP and group-scoped variants.
• Integration groups: GET and POST /v1/integration-groups, POST /v1/integration-groups/{id} to update and DELETE to remove.

The data itself

These two are the interesting ones.

• GET /v1/source/{id}/data?page=1&pageSize=100 returns the rows a data source reads. Paginated.
• GET /v1/integration/{id}/data returns the data from an integration's source, with a POST form that accepts global variables so you can parameterise it, for example by date range.

If a customer has an integration that pulls sales orders out of their ERP, that second endpoint hands you those rows without you writing an ERP connector. The shape of the rows is whatever the customer's mapping produces, so it is customer-specific and must be discovered per tenant, but it is real business data.

Connections and data sources

• GET /v1/connection lists connections visible to the user, and POST /v1/connection filters them.
• GET /v1/connection/{id} returns one.
• GET /v1/connection/{id}/sources?includeProcesses=true lists data sources on a connection.
• GET /v1/connection/{id}/integrations-source and .../integrations-target list processes using that connection as a source or as a destination. Together these give you the full topology of a customer's integration estate, which is a genuinely useful discovery tool on a first technical call.
• GET /v1/source and GET /v1/source/{id} cover data sources directly.

Runs, errors and monitoring

• GET /v1/schedule?scheduleStatus=active lists schedules, GET /v1/schedule/{scheduleId} returns one schedule with its last ten runs.
• GET /v1/schedule/{scheduleId}/runs returns up to the last 100 runs.
• GET /v1/schedule/{scheduleId}/runs/{runNumber}/error and .../integration return the full error text for a run.
• GET /v1/errors lists process error records, GET /v1/errors/{id} returns the failed data, PATCH /v1/errors/{id} updates a failed record so it can be reprocessed, and DELETE /v1/errors/{id} discards it.
• GET /v1/integration/{id}/errors and GET /v1/integration/{id}/error/{runNumber}?includeErrorData=true are the per-process forms.
• GET /v1/events?page=1&pageSize=1000 returns event logs, and DELETE /v1/events/{deleteType} prunes them.

The error model is the most operationally valuable part of the API: the failed rows are retained, readable, editable and reprocessable through the API rather than only through the user interface.

Files, translations and metadata

• GET /v1/file lists files, GET /v1/file/{id} downloads one.
• Translation tables have full create, read, update and delete at /v1/translation.
• GET /v1/$meta lists all enum types, with specific endpoints for connector types, source types, SmartConnect deployment types, Dynamics GP extender types, days of the week, months and week ordinals. Call /v1/$meta/connection-types and /v1/$meta/source-types first: they tell you what the customer's tenant can actually talk to.

Writing back: listings, price and stock

SmartConnect does not write business objects. It runs integrations that do.

• GET /v1/run-integration/{id}?returnErrors=true&returnProcessErrors=true triggers a process. The documentation is explicit that no input variables can be supplied on this form.
• POST /v1/run-integration/{id} runs the process and applies supplied run-time variables, which is the form to use for anything parameterised.

The response is the same either way:

{
  "Key": "<uuid>",
  "Id": "<string>",
  "Description": "<string>",
  "RunNumber": "<long>",
  "Status": "<string>",
  "RecordCount": "<integer>",
  "ErrorCount": "<integer>",
  "Errors": {
    "CurrentPage": "<long>",
    "PageSize": "<long>",
    "RecordCount": "<long>",
    "Columns": [{ "Item1": "<string>", "Item2": "<string>" }],
    "Rows": []
  }
}

That is a good shape to build on: a run number to correlate against, a status, a record count, an error count and the failing rows inline when you ask for them. A connector can fire an integration and know immediately whether it worked and which records did not.

So the write pattern is: land your data where the customer's integration reads it (a file, a SQL table, a REST endpoint), call POST /v1/run-integration/{id} with variables, check ErrorCount, and reprocess through /v1/errors/{id} if needed.

Schedules can also be created and changed through the API: POST /v1/schedule, PATCH /v1/schedule/{scheduleId} and DELETE. That means a connector can provision its own recurring job in the customer's tenant rather than asking an administrator to click through the interface, which is unusual and worth exploiting.

Translation tables are writable too, which is how you would maintain a channel-code to ERP-code mapping from our side rather than by hand.

Webhooks and notifications

The REST API defines no outbound webhook, no subscription endpoint and no signature scheme. There is no callback when a run finishes.

SmartConnect the product does support event-based and change-only triggers, and it can send email alerts on error, but those fire inside the customer's integration, not into a third party.

Poll:

• After triggering a run, the response is synchronous enough to carry status and counts, so no poll is needed for the immediate result.
• For scheduled integrations you did not trigger, poll GET /v1/schedule/{scheduleId}/runs or GET /v1/integration/{id}/history at an interval matched to the schedule, not faster.
• For failures, poll GET /v1/errors on a slower cadence, hourly is usually enough, and alert on growth rather than on presence.

Rate limits and pagination

No rate limit, quota header or burst policy appears in the Swagger specification or in the Postman collection.

Pagination is real but inconsistent. GET /v1/source/{id}/data takes page and pageSize, the Postman example using 1 and 100. GET /v1/events takes the same, with an example page size of 1000. Several list endpoints take no pagination at all. The run response nests its own pagination inside the Errors object with CurrentPage, PageSize and RecordCount, which is the only place a total is returned.

Hard limits stated in the specification: GET /v1/schedule/{scheduleId}/runs returns at most the last 100 runs, and GET /v1/schedule/{scheduleId} returns the last 10 runs with the schedule. Design history collection around those ceilings and collect often enough not to lose runs.

Mapping to the unified model

SmartConnect holds no commerce object, so there is no direct mapping. The table below records what the API does hold and where it lands on our side, so that an integration-health surface can be built from it.

Gaps and open questions

• The row shape from /v1/source/{id}/data and /v1/integration/{id}/data is entirely customer-specific. There is no schema to code against in advance, only GET /v1/integration/{id}/columns to discover it at run time.
• No rate limit, quota header or concurrency guidance is published.
• Pagination is present on some endpoints and absent on others, with no total count except inside the run error object.
• No outbound webhook. A long-running integration triggered through the API has no completion callback beyond the synchronous response, and how the API behaves for a run that outlives the HTTP request is not documented.
• Whether the REST API is available for on-premise SmartConnect installations is not stated, though a deployment-type metadata endpoint implies the two differ.
• The password grant means storing a user password. Whether a client-credentials or service-principal flow exists for unattended use is not documented, and it is the first thing to ask eOne.
• Scopes are declared as empty in the security definition, so the token carries whatever the user can do. There is no way to issue a read-only credential from the API surface.
• Error columns arrive as Item1 and Item2 tuples rather than named fields, which is a serialisation artefact rather than a design, and may change.
• No deprecation policy, changelog or version history is published for v1.
• The public Swagger is hosted on an azurewebsites.net address. That is fine for reading the contract, but a customer's real base URL comes from their own API Settings screen and must be used instead.
• Commercial terms are published as plans for mid-market companies without a public price on the main product page. Pricing is behind a shop page and a partner pricing page.
• eOne acquired DataBlend in 2025. Whether DataBlend's connectors and API converge with SmartConnect's is unresolved and worth asking if finance-system integration is in scope.

Sources

• SmartConnect REST API Swagger specification, read 2026-09-22. Swagger 2.0, title "SmartConnect REST API", version v1, 42 paths, OAuth 2 password flow with token URL /token. Source of every path and operation on this page
• SmartConnect REST API Swagger UI, read 2026-09-22
• First party Postman collection "SmartConnect REST API", uid 2122723-ce45439e-ed72-4445-a463-46a15b7d1b22, retrieved 2026-09-22. Source of the application registration steps, the token and refresh token request bodies, the integration search request body and the run response schema
• eOne Solutions SmartConnect product page, read 2026-09-22. Positioning, connector list, deployment options, trigger types
• eOne Solutions about page, read 2026-09-22. Founded 2001 in Sydney, headquartered in Fargo, North Dakota, offices in Austin, Sydney and Copenhagen, approximately 6,000 customers in 47 countries through 350 or more partners, DataBlend acquired in 2025
• eOne Solutions knowledge base, the product documentation index
• SmartConnect login, where the application registration is done
• DNS checks on 2026-09-22: smartconnect.com and smartconnect.eonesolutions.com resolve to the same address as eonesolutions.com and redirect to the product page; smartconnect.in is an unrelated personalised email and URL service; docs.eonesolutions.com and api.eonesolutions.com do not resolve