Skip to main content
The Manage Manifests endpoint is the primary mutation surface for the manifest lifecycle in Shiipp. Rather than exposing separate routes for each operation, it uses a single action field to route the request to the appropriate handler — covering everything from manifest creation and metadata updates to package assignment and final deletion. All mutating operations are recorded in the manifest audit trail.

Endpoint

Authentication

All requests must include a valid JWT Bearer token in the Authorization header.

Request Structure

Every request must include an action field that identifies the operation to perform. Additional fields are required or optional depending on the chosen action.
string
required
The operation to execute. One of: create_manifest, update_meta, add_packages, remove_packages, delete_manifest.

Actions

Creates a new manifest. This action mirrors the behavior of POST /api/CreateManifest.php and is provided for workflows that prefer a single endpoint.Additional fields:
string
Air Waybill number. Triggers automatic airline prefix detection.
string
Explicit airline prefix override. Ignored when awb_number is provided.
string
Scheduled flight date in YYYY-MM-DD format.
string
Initial notes to store on the manifest record.
string
UUID of the target warehouse. Defaults to the tenant’s primary warehouse.
Response data: manifest_id, manifest_number, status: "draft".

Example Request — Change Status to Shipped

Success Response

Error Responses

Email notifications to courier partners are dispatched after the database transaction commits successfully. Delivery failures are logged in Shiipp’s internal notification log but do not affect the API response — a 200 is returned regardless of email delivery outcome.
Use the remarks field on any update_meta call to leave a human-readable note in the audit trail. This is especially useful when advancing status to shipped or completed to capture flight details or operator sign-off notes.