REST API, AccessKey and scheduling

API calls are authenticated with an AccessKey and SecretKey pair. AccessKeys are issued by a system administrator to the users who are approved to integrate, so a key carries the permissions of the user it was issued to. Pair the key with a dedicated integration account holding the narrowest role that can run the required jobs, rather than issuing a key to an administrator.

Field-level endpoint parameters are versioned with the product and ship in the release package, because paths change between releases while the model below does not. This page documents the part that stays stable: who can call, what can be triggered, and which operations the API cannot perform.

A job is a task that runs on a schedule. Bridge supports ten scheduling modes, and the mode is a property of the job rather than of the caller — which is why an API-triggered run inherits the job's retry and timeout settings.

Two scheduling behaviours are worth knowing before you design an orchestrator. Per-second and real-time schedules can be set to exclusive resource mode, which reserves capacity so the job starts on time — at the cost of delaying other jobs. And retry, validity period and timeout alerts are configured on the schedule itself, so they belong in your go-live checklist, not in a later hardening pass.

The API is not a second, more powerful console. Several operations are deliberately blocked, and knowing which ones prevents building automation that fails halfway.

Promotion between environments runs through password-protected archives rather than a direct push. The mechanics are specific enough to plan around:

1. Export. Select the transformations or jobs, choose export from the more-actions menu, set an archive password, and the browser downloads a .zip file. Export-all is available for a full environment snapshot.
2. Import. Choose import, enter the archive password and upload the .zip. Imported transformations arrive in a ready state.
3. Incremental transformations. These are deactivated on import. The first run sets the incremental start position from the current table position, so imported incrementals do not replay history unless you design them to.
4. Name collisions. A resource whose name already exists is skipped rather than overwritten. When you then import a job, references are re-established against the existing resource of that name.

The last rule is the important one for pipelines run in both directions: an import is additive and never a merge. If you are promoting a changed definition into an environment that already has one, the existing resource wins and your change is silently skipped — so diff by hand or rename before import.

Automation does not only run through the API. Three surfaces are documented here, and each one is worth exercising in the same POC as the API itself:

Whatever the surface, the advice is the same: test promotion into a second environment before you depend on it. Environment promotion is where integration designs usually break, and archive import carries two behaviours — name-collision skipping and incremental deactivation — that quietly change what "promoted" means.

The operation log records who logged into the system, from which IP address, and what they then changed across connection management, transformation management and job management. Auditors can read every user's log; non-auditors see their own entries and their tenant's.

For automation this matters in one specific way: a key issued to an integration account produces entries attributable to that account, so a misbehaving orchestrator is visible as a distinct actor rather than blended into a human operator's history.