Submit an HTML form with an Authorization header

For an original equipment-return form, the API expects a POST containing an asset reference and an optional photograph. The form can collect those values normally. Authentication changes the request construction and error handling, not the field names the server expects.

Keep validation and capture the values before disabling controls

Suppose the existing page contains a form with ID equipment-return, a required named asset field, an optional named photo file input, and one named submit button. The API accepts multipart data at /api/equipment-returns.

This application integration assumes getCurrentAccessToken() is supplied by the existing authentication system and #return-status is a visible status paragraph:

const form = document.querySelector('#equipment-return');
const status = document.querySelector('#return-status');
let sending = false;

form.addEventListener('submit', async (event) => {
  event.preventDefault();
  if (sending) return;
  sending = true;
  status.textContent = 'Sending return…';

  try {
    const body = new FormData(form, event.submitter);
    const token = await getCurrentAccessToken();
    if (!token) {
      status.textContent = 'Sign in again before sending.';
      return;
    }

    const response = await fetch('/api/equipment-returns', {
      method: 'POST',
      headers: { Authorization: `Bearer ${token}` },
      body
    });

    if (response.status === 401) {
      status.textContent = 'Your sign-in needs attention. Keep this form open.';
    } else if (response.status === 403) {
      status.textContent = 'This account cannot submit this return.';
    } else if (!response.ok) {
      status.textContent = `Server returned HTTP ${response.status}. Check the return before retrying.`;
    } else {
      status.textContent = 'The server accepted the return.';
    }
  } catch {
    status.textContent = 'Could not confirm the result. Check before retrying.';
  } finally {
    sending = false;
  }
});

The endpoint and token function are integration points to implement, not services created by the snippet. Normal browser validation runs before this submit event for a form without novalidate; calling form.submit() bypasses that event. The HTML submission guide explains those event rules.

The body is captured before awaiting authentication, so it represents that submission's entries. If you disable fields for a pending state, do it after collecting the FormData: disabled fields are excluded. The sending guard prevents this handler from starting a second concurrent request, but it does not prevent a repeated submission after an uncertain network result. Use the service's supported request-identity or duplicate-handling policy for that case.

Let the browser write the multipart boundary

For a FormData body, omit Content-Type. The browser creates the multipart header with the boundary needed to parse the photograph and text fields. Setting multipart/form-data yourself omits that generated boundary. FormData constructor

A hidden field named Authorization becomes a body field; it does not become a header. Putting the token in action or another URL can expose it in places that record URLs. Send only the credential format that the API specifies, over HTTPS outside a local development environment.

If the receiver wants JSON, build its documented JSON object and set the corresponding Content-Type instead. Do not convert a photograph-bearing FormData to JSON and expect file bytes to survive.

Distinguish a rejected token from a CORS failure

For the same-origin route above, there is no cross-origin CORS exchange. If the API is on a different origin, a request with Authorization requires a preflight. The API must permit the page's origin, POST method, and Authorization header. Configure that on the receiving server. CORS request rules

mode: 'no-cors' cannot turn this into an authenticated, readable API response. Likewise, credentials: 'include' is not a replacement for setting an explicit bearer header; cookie-based authentication has its own server and browser conditions.

In the development Network panel, inspect whether the preflight was allowed and whether the actual POST followed. A visible 401 or 403 response calls for the service's authentication or permission handling. A browser-blocked response can leave JavaScript unable to read a useful HTTP status.

Confirm the record before clearing the form

Use a test account and fictional asset reference. Check the request's named fields and file part without copying its token into screenshots or shared logs. Verify the accepted record through the actual service. Then try an expired session and a permission-denied account; both should leave the entries available.

A network error can occur after the server receives a request. Before prompting a retry, consult the service's accepted-result contract or record view. Clear the form only when that contract confirms the intended equipment return, rather than when fetch merely starts.