Connection and Authentication

SysTrack API Requests

iPaaS.com API Requests

Add/Update SysTrack User TO iPaaS.com

Add SysTrack Sensor Event TO iPaaS.com

Update SysTrack Autofix Run FROM iPaaS.com

Unsupported Operations

Description: The integration checks all five authentication settings before it requests a token. The CLIENT ID setting is empty on the subscription, so no token request is attempted and no SysTrack call is made.

Resolution: Open the SysTrack subscription settings and populate CLIENT ID. The value is shown on the SysTrack Cloud Tenant Information page. Confirm it is the Client Id for the same SysTrack region as the API URL on the subscription, then save and retry the transfer.

Description: The USER NAME setting is empty on the subscription, so the token request is not attempted.

Resolution: Open the SysTrack subscription settings and populate USER NAME. It is the Tenant ID value from the SysTrack Cloud Tenant Information page with @cloud.api appended. Save and retry the transfer.

Description: The PASSWORD setting is empty on the subscription, so the token request is not attempted.

Resolution: Open the SysTrack subscription settings and populate PASSWORD with the service account password. It is set on the SysTrack Manage Service Accounts page; if nobody recorded it when the account was created, reset it there rather than guessing. Save and retry the transfer.

Description: The ROPC POLICY setting is empty on the subscription, so the token request is not attempted. The ROPC_Flow wording in the message refers to the ROPC POLICY setting.

Resolution: Open the SysTrack subscription settings and populate ROPC POLICY. This value is not displayed anywhere in the SysTrack administration pages — SysTrack Support supplies it. Enter it exactly as supplied, including case, as a bare policy name rather than a full address. Save and retry the transfer.

Description: The TENANT NAME setting is empty on the subscription, so the token request is not attempted.

Resolution: Open the SysTrack subscription settings and populate TENANT NAME. Like ROPC POLICY, this value is supplied by SysTrack Support and is not shown in the SysTrack administration pages. Enter it exactly as supplied, including case, as a bare name rather than a full address. Save and retry the transfer.

Description: All five settings were present, the token request was sent to Azure AD B2C, and no usable access token came back. The usual causes are an incorrect or expired service account password, a USER NAME that is not in the required form, a TENANT NAME or ROPC POLICY that does not match the subscriber's tenant (which sends the request to an address or policy that does not exist), or a CLIENT ID belonging to a different SysTrack region than the one the subscription points at.

Resolution: Work through the four settings in that order. Confirm the service account password still works and has not been rotated or expired. Confirm USER NAME is the Tenant ID value with @cloud.api appended. Confirm TENANT NAME and ROPC POLICY match what SysTrack Support supplied, including case. Confirm CLIENT ID matches the region of the API URL. Note that the integration re-authenticates with the stored password on essentially every connection, so a password change in SysTrack breaks the integration immediately rather than gradually — update PASSWORD on the subscription at the same time you rotate it. If all five values are confirmed correct and sign-in still fails, ask SysTrack Support to verify the service account is still linked to the tenant.

Description: SysTrack returned a status other than success for the named request, and the integration includes the response body and HTTP status code verbatim. The {action} portion names the request that failed. The status appears in the parentheses as a name rather than a number, so look for Unauthorized or Forbidden (401/403) when the access token has expired or the service account lacks permission on the requested area, NotFound (404) when the requested user, system, or sensor does not exist on the tenant, and TooManyRequests (429) or a 5xx server status when SysTrack is throttling or temporarily unavailable.

Resolution: Read the status name in the parentheses first. For Unauthorized or Forbidden, re-check the authentication settings as described above and confirm with SysTrack Support that the service account has access to the endpoints in use. For NotFound, confirm the record still exists in SysTrack; a record removed at the source keeps failing on every polling cycle until the corresponding iPaaS.com record is reconciled by hand, because deletions do not propagate. See also the general Resource Not Found Errors article. For TooManyRequests or a 5xx status, the condition is usually transient: avoid running large manual syncs concurrently, stagger bulk jobs, and lower API Throttle Limit or raise API Throttle Seconds on the subscription if the pattern repeats.

Description: There is no fixed message text for this case: what follows the code is the transport error reported by the connection attempt, for example a name resolution failure, a connection timeout, or a TLS negotiation failure, and no HTTP status is present. The request never reached SysTrack. This points at an incorrect API URL, a network or DNS problem between iPaaS.com and the SysTrack Cloud host, or a SysTrack outage.

Resolution: Confirm API URL is the correct regional SysTrack Cloud API address for the tenant and that it is entered without a trailing path. Confirm the SysTrack Cloud dashboard is reachable for the same tenant from a browser. If the dashboard loads and the address on the subscription is correct, the failure is between iPaaS.com and SysTrack rather than in the subscription settings — retry once, since transport failures are frequently transient.

Description: One of the calls that writes the link between a SysTrack user and an iPaaS.com Customer failed, and the appended text is the underlying reason. The token at the start of the message is an internal operation name and carries no subscriber meaning; it is reproduced here only so the message can be found by searching the Error Logs. It most often appears while the integration is trying to link an incoming SysTrack user to an existing iPaaS.com Customer by email address.

Resolution: This is an integration-level failure rather than something to correct in the subscription settings. Re-run the transfer once, in case the failure was transient. If it recurs, contact iPaaS.com Support at support@ipaas.com and quote the appended message text.

Description: Email address is a required field on the iPaaS.com Customer record, and the SysTrack user being transferred has none on file. This error is raised by the collection's EmailAddress mapping before the Customer is created, so the record does not transfer. SysTrack does not collect an email address for every user, so on some tenants this affects a meaningful share of the roster.

Resolution: Populate the user's email address in SysTrack and re-run the transfer. Editing the mapping to return an empty value does not help — the field is required, so that only moves the rejection from the mapping to the iPaaS.com Customer record. Where a user legitimately has no email address and never will, exclude them upstream by applying a mapping collection filter such as !String.IsNullOrEmpty(Email) && Email != "Not collected", which prevents the error instead of raising it on every polling cycle. Not collected is the literal placeholder SysTrack stores for a user whose email was never gathered. Validate the population rate of this field against your own SysTrack tenant in a staging environment before relying on this collection in production.

Description: A transfer was requested for a SysTrack user account number that was empty, or that returned no matching user from SysTrack. This normally means the user was removed or renumbered in SysTrack after the transfer was queued, or that a manual sync was submitted with an account number that does not exist on the tenant.

Resolution: Confirm the SysTrack user account number is correct and that the user still exists on the tenant. For a manual sync, re-submit with a valid account number. Where the user was genuinely removed in SysTrack, note that deletions do not propagate: the iPaaS.com Customer remains and must be reconciled by hand.

Description: The SysTrack account number supplied for a Customer was not a whole number. SysTrack user account numbers are numeric, so a value carrying letters, punctuation, or surrounding text cannot be used as the record key. The rejected value is shown at the end of the message.

Resolution: This most often follows a manual sync submitted with a mistyped or wrongly formatted identifier. Compare the value in the message against the SysTrack user account number as SysTrack reports it, and re-submit using the numeric form exactly.

Description: The scheduled poll that collects SysTrack users could not complete. The appended text carries the underlying reason, most often an authentication failure or an error response from SysTrack; look for a matching entry from the sections above in the same run.

Resolution: Resolve the underlying error identified in the appended text — most commonly by correcting the authentication settings or waiting out a SysTrack availability issue — and allow the next polling cycle to run. Because each cycle retrieves the full user list rather than only recent changes, a large tenant makes this call heavier than a typical incremental poll; if it fails repeatedly under load, lower API Throttle Limit or raise API Throttle Seconds on the subscription.

Description: Before importing a SysTrack user, the integration looks for an existing iPaaS.com Customer with the same email address so the two can be linked rather than duplicated. The link was attempted but did not save with the expected SysTrack account number, so the incoming user may be created as a second Customer record alongside the existing one.

Resolution: Search iPaaS.com for Customer records sharing the email address named in the run and merge or remove the duplicate if one was created. Then re-run the transfer for that user so the link is written correctly. If duplicates keep appearing for the same user, contact iPaaS.com Support at support@ipaas.com with the email address and the run time.

Description: A transfer was requested for a message whose identifier was empty, or that was not in the required sensor-and-system form. The identifier must contain both parts separated by a vertical bar; a single value or a malformed one is rejected before any SysTrack call is made.

Resolution: For a manual sync, re-submit using the full identifier in the form sensor identifier, vertical bar, system identifier, taking both values from the SysTrack sensor result. Note that this code and SYST-NFND-1001 share the same message text but belong to different flows — the code tells you which one you are looking at.

Description: SysTrack returned sensor results for the requested system, but none of them matched the requested sensor identifier. The system exists; the sensor named in the message does not belong to it, or its result is no longer retained on the tenant. Both identifiers are named in the message so the specific pairing can be checked directly.

Resolution: Confirm in SysTrack that the sensor identifier and system identifier named in the message belong together and that the sensor result is still available on that machine. Sensor results age out, so an alert queued for transfer well after it fired may no longer be retrievable. Re-run the transfer with a current sensor result, or allow the next polling cycle to import current alerts.

Description: This message wraps every failure of the outbound remediation dispatch, and the appended text carries the specific reason. Because it is a wrapper, the appended text frequently contains a second code — SYST-VALD-1002 or SYST-VALD-1003 below, or one of the SysTrack API Requests codes when SysTrack itself rejected the remediation request. Search this page for the inner code rather than this one when a second code is present.

Resolution: Read the appended text and follow the resolution for the inner code it names. Where the appended text names no code, it is the raw text of an unexpected failure — re-run the transfer once, and if it recurs, contact iPaaS.com Support at support@ipaas.com with the full message.

Description: Before dispatching the remediation, the integration checks that the iPaaS.com Message still carries the SysTrack external identifier it was imported with. This error means that identifier is absent, so the integration cannot tie the remediation back to a SysTrack sensor and system. Despite the wording, only the presence of the identifier is checked, not its form — a value in some other shape is not reported through this message.

Resolution: Confirm the Message was originally imported from SysTrack by the Add SysTrack Sensor Event TO iPaaS.com collection. Messages created directly in iPaaS.com, or Messages whose external identifier has been cleared or edited, cannot be dispatched outbound. Re-import the alert from SysTrack and transfer the resulting Message instead.

Description: The outbound transfer reached SysTrack-request stage without a sensor identifier, or SysTrack accepted the request but returned no batch identifier, so there is nothing to record back on the Message. Either way the remediation is not confirmed as queued.

Resolution: Check that the Message being transferred carries values in SysTrack System Id, SysTrack Sensor Automation 1 Sensor Id, and SysTrack Sensor Automation 1 Application Id, and that the mappings supplying them have not been cleared. Note that a populated automation identifier is not a guarantee that the automation matches the alert; SysTrack does not expose a relationship between a sensor's name and an automation's name, as described in the SysTrack Integration Known Limitations article. Confirm the automation and sensor pairing in SysTrack, then re-run the transfer.

Description: The integration reads SysTrack users into iPaaS.com and never writes them back, so creating a SysTrack user from iPaaS.com is not implemented and no SysTrack call is made.

Resolution: Create the user in SysTrack instead. Confirm that no mapping collection or subscription event is configured to send Customer data toward SysTrack, and remove any that is. See the SysTrack Integration Known Limitations article for the full directionality summary.

Description: Deleting a SysTrack user from iPaaS.com is not implemented, so the attempt fails and nothing is removed in SysTrack.

Resolution: Remove the user in SysTrack instead. Deleting the Customer in iPaaS.com removes only the iPaaS.com record; the two sides must be reconciled by hand. Confirm no delete event is enabled against the Customer collection.

Description: Writing user field values back to SysTrack is not implemented, so the attempt fails and no SysTrack call is made.

Resolution: Make corrections to a person's name, email address, or account number in SysTrack rather than in iPaaS.com; the next transfer brings the corrected values across. Confirm the Customer collection is configured TO iPaaS.com only.

Description: Sensor alerts originate in SysTrack. Creating a new SysTrack sensor event from iPaaS.com is not implemented, so the attempt fails.

Resolution: Confirm the outbound Message collection is configured for the update action only, and that no create event is enabled against it. The only supported outbound action on a Message is the remediation dispatch described above.

Description: Deleting a SysTrack sensor event from iPaaS.com is not implemented, so the attempt fails and nothing is removed in SysTrack.

Resolution: Confirm no delete event is enabled against the Message collection. Deleting a Message in iPaaS.com removes only the iPaaS.com record; nothing is removed in SysTrack, and the two sides must be reconciled by hand.

iPaaS.com <> SysTrack: Background

SysTrack Installation Instructions

SysTrack Connections and Settings

SysTrack Mapping Functions

SysTrack API Endpoints

SysTrack Integration Known Limitations