Artifacts
Artifacts are named, non-sensitive reference files stored centrally on the platform. Upload a file once, give it a name, and every adapter that needs that file selects it from a dropdown during configuration.
The decoupling is deliberate. A reference file that ten adapters depend on is one artifact, not ten copies pasted into ten adapter configurations. Update the file in one place and every dependent adapter moves to the new version on its next restart.
What counts as an artifact
| File type | When you need it |
|---|---|
| Protocol data dictionary | You are connecting to a system that uses custom or non-standard message formats and the platform needs the dictionary to parse them. |
| Schema definition | A transformer or processor in the pipeline requires a custom schema to validate or reshape messages. |
Artifacts are for non-sensitive reference files only. The artifacts store applies no secret-grade encryption or access control to the files it holds, and any Portal user can download them, so certificates, private keys, and other sensitive material do not belong here. Those belong in your infrastructure layer. See Security for where encryption and secret handling live.
Why artifacts are separate from adapters
Putting reference files inside each adapter would mean re-uploading the same dictionary for every new connection to the same counterparty, and editing every adapter when the dictionary changes. The artifacts store exists so the reference file is the single source of truth, regardless of how many adapters depend on it.
| Scenario | Without a shared artifacts store | With the artifacts store |
|---|---|---|
| Many adapters share the same dictionary | Every adapter carries its own copy. Updates require editing each one. | Every adapter references the same named artifact. One upload covers all of them. |
| The dictionary changes | Risk of drift: some adapters on the old version, some on the new. | Upload the new file under the existing name. Every dependent adapter picks up the new version on its next restart. |
| An adapter is deleted | The file goes with it, even if other adapters still need it. | The artifact survives. Other adapters keep running. |
Uploading an artifact
- Open Artifacts in the Portal.
- Click Upload.
- In the upload dialog, drop a file onto the drop zone or click to browse, then choose the file from your computer.
- Click Upload to store it.
There is no separate name to enter: an artifact is identified by its filename. Once stored, the file is immediately available for selection in the adapter wizard.
The platform does not restrict the file format. Upload the reference file in whatever form your connector expects (data dictionaries and schema definitions are usually small text files). Each file can be up to 500 MB.
An artifact is identified by its filename, so name the file itself before uploading. Pick a name that conveys the counterparty or purpose, not an internal version number. When you upload a file with the same filename, it replaces the existing artifact in place and adapter references keep working; uploading under a different filename creates a separate artifact and would require editing every dependent adapter.
Using an artifact in an adapter
The adapter wizard has an Artifacts step that lists every uploaded artifact as a grid of cards, each showing the file's name, with a search box to filter by filename. Click a card to select the file, and select as many as the adapter depends on. The adapter then references those artifacts for the life of its configuration.
Artifacts are not classified by type. The step shows the whole library; the adapter, or the plugin that consumes the file, is responsible for interpreting the contents.
Updating an artifact
Reference data changes over time: counterparties issue revised dictionaries; internal schemas evolve. The platform supports this as an overwrite keyed on the filename.
- Open Artifacts in the Portal.
- Upload the new file using the same filename as the existing artifact.
- The platform replaces the content stored under that filename. When the picked file matches an existing artifact, the upload dialog shows a notice that it will replace the artifact in place and that adapters referencing it stay linked.
An adapter loads its artifact when the session starts. Uploading a new version does not interrupt a running session and does not change what the running adapter is using.
To apply the change, disable the adapter, wait for Status to reach Inactive, then enable it again. Plan this restart during a maintenance window for production connections; the restart closes the session cleanly, but any external system that tracks session uptime will observe the reconnect.
If multiple adapters depend on the artifact, every one of them needs a restart to adopt the new version. Treat the upload as the first step of a coordinated rollout, not the whole change.
Deleting an artifact
- Open Artifacts in the Portal.
- Click the delete (trash) icon on the artifact's row.
- Confirm in the dialog. Deletion is permanent and cannot be undone.
The platform does not block deletion of an artifact that adapters still depend on, and it does not warn you which adapters reference it. Deleting an artifact also removes it from any adapter configurations that referenced it, so those adapters lose the file.
Because nothing guards this for you, check dependents before you delete. If an adapter still needs the artifact, first edit that adapter to remove the reference or point it at a different artifact, save, and restart it if it was running. Then delete the artifact.
See also
- Creating an Adapter: where artifacts are selected during configuration.
- Security: where certificates, keys, and other sensitive material are handled.
- Plugins: the connectors and components that consume artifacts.