Managing Deployments with the FileWave API (16.4+)

What

FileWave 16.4 adds supported public API endpoints for creating, listing, reading, updating, and deleting Deployments. These endpoints allow integrations and administrative automation to manage the same Deployment objects used by FileWave Central and FileWave Anywhere.

Version boundary: The public Deployments API described here requires FileWave Server 16.4.0 or later. Earlier FileWave versions do not provide these public Deployment endpoints.

Deployment endpoints

Use HTTPS on the FileWave Server hostname. For example, the collection endpoint is https://<filewave-server>/filewave/api/deployments/public/deployments.

Authentication and permissions

For scripts and integrations, send a FileWave administrator application token in the Authorization header. Application tokens are created and revoked in FileWave Central under Assistants > Manage Administrators > Application Tokens.

Authorization: <base64-application-token>

• Use a dedicated administrator identity with only the FileWave permissions the integration requires.
• Store the token in a secret manager or protected environment variable rather than in source code.
• Do not include real tokens, server names, Deployment IDs, or payload data in public examples or support screenshots.
• Revoke and replace a token if it is exposed.

Confirm the current schema in Swagger

Sign in to FileWave Anywhere, then open https://<filewave-server>/api/doc/. Search the Swagger/OpenAPI documentation for deployments to inspect the request body, required fields, identifier format, response schema, and current status codes on that Server version.

Do not build create or update payloads from guesses or private/internal endpoints. Use the public paths above and the schema published by the target FileWave Server. A PUT request is not a promise of PATCH semantics; submit the complete body required by the documented operation.

Swagger uses an X-CSRFToken for commands run inside its documentation page. A standalone script should instead use the FileWave application token described above. Do not copy the Swagger session token into production automation.

Read-only example

This example lists Deployments without modifying the FileWave Model:

export FILEWAVE_SERVER='filewave.example.com'
export FILEWAVE_TOKEN='<base64-application-token>'

curl --fail --silent --show-error \
  -H "Authorization: ${FILEWAVE_TOKEN}" \
  -H "Accept: application/json" \
  "https://${FILEWAVE_SERVER}/filewave/api/deployments/public/deployments"

After obtaining a Deployment identifier from the list response, inspect that object with GET /filewave/api/deployments/public/deployments/<id> before changing or deleting it.

Safe write workflow

1. Use GET to record the current Deployment and related object identifiers.
2. Build the create or update body from the target Server’s Swagger schema.
3. Test against a non-production Deployment and a limited target set.
4. Submit the POST or PUT request and capture the HTTP status plus response body.
5. Read the resulting Deployment back with GET and confirm its Filesets, targets, exclusions, installation type, timing, license distribution, and tags.
6. Review the Deployment in FileWave Central before updating the FileWave Model or expanding its scope.

DELETE is destructive. Confirm the Deployment identifier and current contents immediately before sending the request. Do not assume the API provides a preview, recycle bin, or automatic rollback.

Troubleshooting

Related Content

• Working With APIs
• FileWave Anywhere API Documentation
• Deployments in FileWave Central
• What makes Deployments better than Associations?