The create-verification response returns a direct upload target. The customer uploads the raw file bytes to that target before processing can begin.

Upload object from the create response

The upload object can include:

• method: HTTP method to use for the direct upload
• url: presigned storage URL
• headers: optional storage-specific headers that must be forwarded exactly
• expires_at: upload-target expiry time

Treat the object key behind that URL as opaque. It is intentionally non-discoverable.

Example upload

curl -X PUT "<signed-upload-url>" \
  --upload-file "/absolute/path/to/belge.pdf"

Integration rules

• Send the raw file bytes, not multipart form data.
• Use the exact method, url, and any returned headers from the create response.
• Do not invent or rewrite the storage object key.
• The platform does not require you to declare the real MIME type up front.
• The later upload-complete step checks the stored object size against the declared file_size_bytes from create.

Retry behavior

If a create request is retried with the same Idempotency-Key while the job is still waiting for upload, the platform can reuse the same verification job and return another direct upload target for that pending object.

What happens after the bytes arrive

The upload itself does not start verification processing. After the bytes are present in storage, call the upload-complete endpoint so the server can validate the object and move the job into processing.

Next pages

• Create the verification first
• Confirm upload completion
• Fetch or receive the final result